socket_dist_controller: sends can block the controller and hide a dead peer
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 47/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- erlang
- Domain
- backend, networking
Research direction
Start with libs/estdlib/src/socket_dist_controller.erl, especially the tick handler and send_data_loop, and trace how the controller stores pending data and handles socket notifications. Check OTP distribution's nowait send behavior for context. Done means sends no longer block the controller, pending data resumes on write notification, and a blocked send beyond the tick timeout fails the connection.
Written by the indexing model from the issue text.
Description
socket_dist_controller (libs/estdlib/src/socket_dist_controller.erl) sends with socket:send/2 from the tick handler and from send_data_loop.
Since #2345, socket:send/2 waits for the socket to be writable again when the send buffer is full. If the peer stops reading (a hung node, a dead link not yet detected by TCP), the controller gen_server blocks in socket:send/2. It also stops handling tick, which is what should detect a dead peer.
OTP's distribution uses nowait sends for this reason: the controller keeps running, and the sender is notified when the socket can be written.
Possible direction: send with a nowait variant (or socket:nif_send/2 and nif_select_write/2 directly) from the controller, keep the unsent rest in the state, resume from the write notification, and treat a blocked send that lasts longer than the tick timeout as a failed connection.
Raised by @bettio in the review of #2345, where a follow-up issue was agreed.
- 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