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

[Nick Maclaren]

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