ESP32: Non-blocking socket_driver
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c, embedded-iot, erlang
- Domain
- backend, networking
Research direction
Read the existing socket_driver and compare its blocking behavior with the non-blocking PoC in PR #2197 and the linked test branch. Start by reproducing the stalled scheduler with a request to a reachable server port that is not listening; the issue gives no test file or driver path. Done means replacing the old driver so failed connections no longer block the scheduler for seconds.
Written by the indexing model from the issue text.
Description
For about half a year, I've been running some code on a ESP32-S3 that periodically makes HTTP GET requests. Occasionally, it would occasionally completely lock up and need to be restarted. After some experimentation, I was able to reproduce by making a HTTP GET request to a server that was accessible, but not listening on that port. So my hunch is that the HTTP servers I was making requests to would occasionally briefly go down for maintenance or similar and a badly timed request would lock things up.
Turns out there was a deadlock existing driver: fixed here https://github.com/atomvm/AtomVM/pull/2200
Gave this [fix] a quick test:
1970-01-01T00:00:05.485Z [info] <0.18.0> Tick!
1970-01-01T00:00:06.569Z [info] <0.18.0> Tick!
1970-01-01T00:00:06.993Z [debug] <0.33.0> HTTP GET http://foobar/baz
1970-01-01T00:00:25.570Z [debug] <0.33.0> HTTP Error: {error,{gen_tcp,econnaborted}}
1970-01-01T00:00:25.677Z [info] <0.18.0> Tick!
1970-01-01T00:00:27.098Z [info] <0.18.0> Tick!
So that does look like ~18s of stall, which is a lot better than permanently locking up.
But it still stalls the scheduler for 18 seconds, yes we can tune that down to maybe half but still blocking.
@pikdum contributed a non-blocking PoC here in #2197 - that I progressed to PR worthy level (according to LLM, all caveats apply!) here https://github.com/petermm/AtomVM/tree/test-2197
So this issue is to track replacing the old driver.
- Dominant language
- Erlang
- Stars
- 2.3k
- Forks
- 171
- Avg merge
- 4d 11h
- Merged PRs (30d)
- 20
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from atomvm/AtomVM
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 3 days
-
lwIP sockets: a failed listen or connect leaves the socket lock held, a later close hangs foreverOpen
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 3 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
milind-soni/OpenMausBot#5829 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
finos/fluxnova-bpm-platform#387 ·
Maintainers usually reply within 4 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
OHDSI/Data2Evidence#3693 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
kubernetes-sigs/headlamp#8408 ·
Maintainers usually reply within 1 day