Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



RT 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


Naively asking: what prevents RT Unix/Linux from being used in place of non-RT mainstream versions? Seems like a superset.


RT signals are an extended API of POSIX you don't need actual RT Linux to use them.


Are they guaranteed to be delivered in order?


Yes as long as you use sigqueue with SA_SIGINFO


Come 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.


That's easily solved, just create a queue for your signals.


It is waiting for NULL! :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: