[Python-Dev] Signals, threads, blocking C functions

[Adam Olsen]

On 9/8/06, Jan Kanis <jan-python at maka.demon.nl> 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?

-- 
Adam Olsen, aka Rhamphoryncus