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

[Gustavo Carneiro]

On 9/9/06, Adam Olsen <rhamph at gmail.com> wrote:
> On 9/8/06, Adam Olsen <rhamph at gmail.com> wrote:
> > 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.
>
> Doh, except that's exactly what sig_atomic_t is for.  Ah well, can't
> win them all.

>From the glibc manual:
"""
To avoid uncertainty about interrupting access to a variable, you can
use a particular data type for which access is always atomic:
sig_atomic_t. Reading and writing this data type is guaranteed to
happen in a single instruction, so there's no way for a handler to run
"in the middle" of an access.
"""

  So, no, this is certainly not the same as linux kernel atomic
operations, which allow you to do more interesting stuff like,
test-and-clear, or decrement-and-test atomically.  glib has those too,
and so does mozilla's NSPR, but only on a few architectures does it do
it without using mutexes.  for instance, i686 onwards don't require
mutexes, only special instructions, but i386 requires mutexes.  And we
all know mutexes in signal handlers cause deadlocks :-(

  And, yes, Py_AddPendingCall and Py_MakePendingCalls are most
certainly not async safe!  Just look at the source code of
Py_MakePendingCalls and you'll see an interesting comment...
Therefore, discussions about signal safety in whatever new API we may
add to Python should be taken with a grain of salt.

  Regards.