On 9/9/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > On 9/8/06, Adam Olsen <[EMAIL PROTECTED]> 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
