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

[Gustavo Carneiro]

On 9/5/06, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
[...]
> Even if write is atomic, there are gotchas.  What if the interrupted
> code is doing something to that file at the time?  Are you SURE that
> an unexpected operation on it (in the same thread) won't cause the
> library function of program to get confused?

  Yes, I'm sure.  The technique is based on writing any arbitrary byte
onto a well known pipe.  Any byte will do.  All it matters is that we
trick the kernel into realizing there is data to read on the other end
of the pipe, so that it can wake up the poll() syscall waiting on it.
Only signal handlers ever write to this file descriptor.  If one
signal handler interrupts another one, it's ok; all it takes is that
at least one of them succeeds, and the data itself is irrelevant.
Only the mainloop ever reads from the pipe.

>  And can you be sure that the write will terminate fast enough to not cause time-critical code to fail?

 Time critical code should block signals.  Or should use a real-time OS.

>  And have you studied the exact semantics of blocking
> on pipes?  They are truly horrible.

  The pipe is changed to async mode; never blocks.  We don't care
about any data being transferred at all, only the state on the file
descriptor changing.

> So this is NOT a matter of platform X is safe and platform Y isn't.
> Even Linux x86 isn't entirely safe - or wasn't, the last time I heard.

  We can't prove write() is async safe, but you can't prove it isn't
either.  From all I know, write() doesn't use malloc(); it only loads
a few registers and calls some interrupt (or syscall in amd64).  It is
plausible that it is perfectly async safe.

   And that's completely beside the point.  We only ask python to call
a function of ours every time it handles a signal.  You are
criticizing the way pygtk or glib will handle the notification, but we
are here to discuss how will Python just give us a small hand in
solving the signals problem.  These are different problem domains.  We
don't ask Python developers to endorse any particular way of solving
our problem.  But since Python already snatches away our beloved
signals, especially SIGINT, it should at least be courteous enough to
give us just a notification when signals happen.  There is _no_ other
way.