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

[Adam Olsen]

On 9/4/06, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
> 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!

I don't believe that is true.  It says (or atleast SUSv3 says) that:

"""  3.26 Async-Signal-Safe Function

A function that may be invoked, without restriction, from
signal-catching functions. No function is async-signal-safe unless
explicitly described as such."""

Sure, it doesn't give me a warm-fuzzy feeling of knowing why it works,
but we can expect that it magically does.  My understanding is that
threading in general is the same way...

Of course that doesn't preclude bugs in the various implementations,
but those trump the standards anyway.

-- 
Adam Olsen, aka Rhamphoryncus