[Python-Dev] Signals, threads, blocking C functions
nmm1 at cus.cam.ac.uk
Mon Sep 4 19:18: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
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