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

Jean-Paul Calderone exarkun at divmod.com
Mon Sep 4 19:55:41 CEST 2006


On Mon, 04 Sep 2006 18:18:41 +0100, 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!
>
>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).
>

Thanks for expounding.  Given that it is basically impossible to do
anything useful in a signal handler according to the relevant standards
(does Python's current signal handler even avoid relying on undefined
behavior?), how would you suggest addressing this issue?

It seems to me that it is actually possible to do useful things in a
signal handler, so long as one accepts that doing so is relying on
platform specific behavior.

How hard would it be to implement this for the platforms Python supports,
rather than for a hypothetical standards-exact platform?

Jean-Paul


More information about the Python-Dev mailing list