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

[Gustavo Carneiro]

On 9/5/06, Adam Olsen <rhamph at gmail.com> wrote:
> On 9/4/06, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> >   Now, we've had this API for a long time already (at least 2.5
> > years).  I'm pretty sure it works well enough on most *nix systems.
> > Event if it works 99% of the times, it's way better than *failing*
> > *100%* of the times, which is what happens now with Python.
>
> Failing 99% of the time is as bad as failing 100% of the time, if your
> goal is to eliminate the short timeout on poll().  1% is quite a lot,
> and it would probably have an annoying tendency to trigger repeatedly
> when the user does certain things (not reproducible by you of course).
>
> That said, I do hope we can get 100%, or at least enough nines that we
> can increase the timeout significantly.

  Anyway, I was speaking hypothetically.  I'm pretty sure writing to a
pipe is async signal safe.  It is the oldest trick in the book,
everyone uses it.  I don't have to see a written signed contract to
know that it works.

  Here's a list of web sites google found me that talk about this problem:

This one describes the pipe writing technique:
  http://www.cocoadev.com/index.pl?SignalSafety

This one presents a list of "The only routines that POSIX guarantees
to be Async-Signal-Safe":
  http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/MTP/p40.html#GEN-95948

Also here:

http://www.cs.usyd.edu.au/cgi-bin/man.cgi?section=5&topic=attributes

  This is all the evidence that I need.  And again I reiterate that
whether or not async safety can be achieved in practice for all
platforms is not Python's problem.  Although I believe writing to a
pipe is 100% reliable for most platforms.  Even if it is not, any
mission critical application relying on signals for correct behaviour
should be rewritten to use unix sockets instead; end of argument.