[Python-Dev] Signals, threads, blocking C functions (original) (raw)

Nick Maclaren nmm1 at cus.cam.ac.uk
Mon Sep 4 19🔞41 CEST 2006

Jean-Paul Calderone <exarkun at divmod.com> wrote:

On Mon, 04 Sep 2006 17:24:56 +0100, David Hopwood <david.nospam.hopwood at blueyon_ _der.co.uk> wrote: >Jean-Paul Calderone wrote: >> PyGTK would presumably implement its pending call callback by writing a >> byte to a pipe which it is also passing to poll(). > >But doing that in a signal handler context invokes undefined behaviour >according to POSIX.

write(2) is explicitly listed as async-signal safe in IEEE Std 1003.1, 2004. Was this changed in a later edition? Otherwise, I don't understand what you mean by this.

Try looking at the C90 or C99 standard, for a start :-(

NOTHING may safely be done in a real signal handler, except possibly setting a value of type static volatile sig_atomic_t. And even that can be problematic. And note that POSIX defers to C on what the C languages defines. So, even if the function is async-signal-safe, the code that calls it can't be!

POSIX's lists are complete fantasy, anyway. Look at the one that defines thread-safety, and then try to get your mind around what exit being thread-safe actually implies (especially with regard to atexit functions).

Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1 at cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

More information about the Python-Dev mailing list