mirror of
https://github.com/tokio-rs/tokio.git
synced 2026-08-16 00:00:12 +02:00
Ivan Petkov
c9ffd98b1e
* As observed in alexcrichton/tokio-signal#38, Signal instances can starve based on the order they are created in, and this ordering appears to be platform/OS specific * The crux of the issue is that we woud only *attempt* to broadcast any pending signals if we successfully read out at least one byte from the global pipe. * For reasons unclear to me, the affected Signal instance would get woken up after the signal handler writes to the global pipe, but it would immediately hit a WouldBlock error and give up, bypassing the broadcast attempt (even though the pending flag was correctly set). - Maybe this has to do with OS specifics with how the bytes are delivered (or not), or with some complex interaction with tokio and the pipe registration. It seems fishy since strace logs didn't show the signal handler pipe write fail either, but I'm all out of ideas * The fix appears simple: unconditionally attempt to broadcast any pending signals *any* time a Driver instance is woken up. * Since we perform an atomic check for each pending signal, we know that each (coalesced) signal broadcast will happen at most once. If we were supuriously woken up and no signals were pending, then nothing will be yielded to any pollers of Signal * The down side is that since each Signal instance polls a Driver instance, each poll to Signal will essentially perform N atomic operations (N = number of signals we support) in an attempt to broadcast any pending signals. - However, we can revisit optimizing this better in the future Fixes alexcrichton/tokio-signal#38