7 ms·
UNIX signals *do not* queue. If two or more signals with the same number are sent faster than the receiving thread handles them (due to the signal being blocke
by gldrk 1y ago
UNIX signals *do not* queue. If two or more signals with the same number are sent faster than the receiving thread handles them (due to the signal being blocked and/or the thread not being scheduled), all but the last will be lost irrevocably. There is no mechanism to prevent this.
https://ldpreload.com/blog/signalfd-is-useless https://ldpreload.com/blog/signalfd-is-useless
- jmalicki 1y agoRT signals do get queued... that is one of the major differences (and yes, the essay is not using them, so your point stands as it is written, but using RT signals is a mechanism to prevent it). https://davmac.org/davpage/linux/rtsignals.html https://davmac.org/davpage/linux/rtsignals.html
- nakamoto_damacy 1y agoNaively asking: what prevents RT Unix/Linux from being used in place of non-RT mainstream versions? Seems like a superset.
- jmalicki 1y agoRT signals are an extended API of POSIX you don't need actual RT Linux to use them.
- kscarlet 1y agoAre they guaranteed to be delivered in order?
- jmalicki 1y agoYes as long as you use sigqueue with SA_SIGINFO
- RedShift1 1y agoThat's easily solved, just create a queue for your signals.
- gldrk 1y agoCome to think of it, I think the original idea can be salvaged with an acknowledgment signal. Send bit, wait for acknowledgment, send next bit or retransmit accordingly. Actually you would need a handshake before each bit.
- johnisgood 1y agoIt is waiting for NULL! :)