Tokio bug: concurrent UDP sends can hang forever on OpenBSD, with a workaround
jedisct1 · x · 2026-10-14
jedisct1 filed a Tokio issue (#8643) showing that concurrent UdpSocket::sendto calls on the same socket can stop making progress indefinitely on OpenBSD 7.9 (Tokio 1.53.3, Mio 1.2.4).
A reproducer with eight tasks sharing one socket reliably hits a 60-second timeout; serializing sends fixes it (80,000 sends in 5.5s). The likely cause: OpenBSD returns EWOULDBLOCK when concurrent sends contend for the socket's send lock, after which Tokio clears writable readiness and waits for an event that never arrives. A per-socket async send mutex is a reliable workaround; the author suggests Tokio serialize sends per UDP socket on OpenBSD.
More from Infra
- Repeated-Data Pretraining Study: Smaller Batches Act as Regularizers and Beat More GPUs — Sewon Min · 2026-10-14
- Liquid Claims 184 tok/s on My Mac — I Measured 174: The Speed Claim Holds — TheOyinbooke · 2026-10-14
- Investor warns undifferentiated neoclouds pivoting to inference face consolidation — AccBalanced · 2026-10-14
- Lightning AI Joins GTC Berlin Panel on GPU Access for AI Startups at Every Stage — LightningAI · 2026-10-14
- Hugging Face to livestream how speculative decoding delivers multipliers in local LLM speed-ups — mervenoyann · 2026-10-14
- The Jensen Huang Playbook: How NVIDIA Built CoreWeave as a Buffer Against Its Biggest Customers — AccBalanced · 2026-10-14