On 9/8/06, Jan Kanis email@example.com wrote:
At the risk of waking up a thread that was already declared dead, but perhaps this is usefull.
I don't think we should let this die, at least not yet. Nick seems to be arguing that ANY signal handler is prone to random crashes or corruption (due to bugs). However, we already have a signal handler, so we should already be exposed to the random crashes/corruption.
If we're going to rely on signal handling being correct then I think we should also rely on write() being correct. Note that I'm not suggesting an API that allows arbitrary signal handlers, but rather one that calls write() on an array of prepared file descriptors (ignoring errors).
Ensuring modifications to that array are atomic would be tricky, but I think it would be doable if we use a read-copy-update approach (with two alternating signal handler functions). Not sure how to ensure there's no currently running signal handlers in another thread though. Maybe have to rip the atomic read/write stuff out of the Linux sources to ensure it's *always* defined behavior.
Looking into the existing signalmodule.c, I see no attempts to ensure atomic access to the Handlers data structure. Is the current code broken, at least on non-x86 platforms?