[Python-Dev] Signals, threads, blocking C functions
gjcarneiro at gmail.com
Tue Sep 5 15:44:14 CEST 2006
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:
This one presents a list of "The only routines that POSIX guarantees
to be Async-Signal-Safe":
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.
More information about the Python-Dev