There are several difficulties using waitSignal, both in single- and multi-threaded contexts:
- on
kqueue, the implementation overwrites signal handlers, but instead of restoring the previously installed handler, it sets it to SIG_DFL:
|
osdefs.signal(sig, SIG_DFL) |
- this introduces a race condition where a second signal after waitSignal completes will crash the application
- this breaks applications that set up their own synchronous signal handler
- as an aside, this prevents applications from handling signals in other threads while
waitSignal is pending
kqueue reacts to process-bound signals - linux reacts to thread-bound signals - if a process-bound signal is sent to linux, it is not likely to reach the waitSignal notification mechanism in a multi-threaded application, but on kqueue it will
- on linux, one must
pthread_kill to reach the right thread that is waiting for waitSignal
- on kqueue, one must
kill instead, to send a process pending
- linux applications must block signals on all other threads while waitSignal is waiting
- windows version of
waitSignal is not interoperable with C signal / raise - on windows, one must use the custom chronos raiseSignal - this means applications written for C11 cannot work with windows' waitSignal at all, for example if chronos is used as a library in a multi-language application like status desktop and they want to raise signals
- depending on the platform,
waitSignal may require that all threads block the relevant signals - waitSignal itself will block signals for its own threads, which means that process-bound signals are unlikely to reach it if there are other threads present - this breaks ctrl-c on windows
Some of the above are bugs - some are consequences of underlying OS differences - depending on which case it is, they should either be resolved or documented in the API.
There are several difficulties using
waitSignal, both in single- and multi-threaded contexts:kqueue, the implementation overwritessignalhandlers, but instead of restoring the previously installed handler, it sets it toSIG_DFL:nim-chronos/chronos/ioselects/ioselectors_kqueue.nim
Line 444 in b55e281
waitSignalis pendingkqueuereacts to process-bound signals -linuxreacts to thread-bound signals - if a process-bound signal is sent to linux, it is not likely to reach thewaitSignalnotification mechanism in a multi-threaded application, but onkqueueit willpthread_killto reach the right thread that is waiting forwaitSignalkillinstead, to send a process pendingwaitSignalis not interoperable with Csignal/raise- on windows, one must use the custom chronosraiseSignal- this means applications written for C11 cannot work with windows'waitSignalat all, for example if chronos is used as a library in a multi-language application like status desktop and they want to raise signalswaitSignalmay require that all threads block the relevant signals -waitSignalitself will block signals for its own threads, which means that process-bound signals are unlikely to reach it if there are other threads present - this breaks ctrl-c on windowsSome of the above are bugs - some are consequences of underlying OS differences - depending on which case it is, they should either be resolved or documented in the API.