[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

[Adam Olsen]

On Dec 8, 2007 2:56 PM,  <glyph at divmod.com> wrote:
> On 05:20 pm, guido at python.org wrote:
> >The best solution I can think of is to add a new API that takes a
> >signal and a file descriptor and registers a C-level handler for that
> >signal which writes a byte to the file descriptor. You can then create
> >a pipe, connect the signal handler to the write end, and add the read
> >end to your list of file descriptors passed to select() or poll(). The
> >handler must be written in C in order to avoid the race condition
> >referred to by Glyph (signals arriving after the signal check in the
> >VM main loop but before the select()/poll() system call is entered
> >will not be noticed until the select()/poll() call completes).
>
> This paragraph jogged my memory.  I remember this exact solution being
> discussed now, a year ago when I was last talking about these issues.
>
> There's another benefit to implementing a write-a-byte C signal handler.
> Without this feature, it wouldn't make sense to have passed the
> SA_RESTART flag to sigaction, because and GUIs written in Python could
> have spent an indefinite amount of time waiting to deliver their signal
> to Python code.  So, if you had to handle SIGCHLD in Python, for
> example, calls like file().write() would suddenly start raising a new
> exception (EINTR).  With it, you could avoid a whole class of subtle
> error-handling code in Twisted programs.

SA_RESTART still isn't useful.  The low-level poll call (not write!)
must stop and call back into python.  If that doesn't indicate an
error you can safely restart your poll call though, and follow it with
a (probably non-blocking) write.

Note that the only reason to use C for a low-level handler here is
give access to sigatomic_t and avoid needing locks.  If you ran the
signal handler in a background thread (using sigwait to trigger them)
you could use a python handler.


-- 
Adam Olsen, aka Rhamphoryncus