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

[Josiah Carlson]

"Adam Olsen" <rhamph at gmail.com> wrote:
> 
> On 9/12/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> > Adam Olsen wrote:
> >
> > > That brings you back to how you access the flags variable.
> >
> > The existing signal handler sets a flag, doesn't it?
> > So it couldn't be any more broken than the current
> > implementation.
[snip]
> My previous mention of using a *single* flag may survive corruption
> simply because we can tolerate false positives.  Signal handlers would
> write 0xFFFFFFFF, the poll loop would check if *any* bit is set.  If
> so, write 0x0, read off the fd, then loop around and check it again.
> If the start of the read() acts as a write-barrier it SHOULD guarantee
> we don't miss any positive writes.
[snip]

I've been lurking on this thread for a while, but I'm thinking that just
a single file handle with a poll/read (if the poll succeeds) would be
fine.  So what if you miss a signal if there is a burst of signal
activity?  If users want a *good* IPC mechanism, then they can use any
one of the known-good IPC mechanisms defined for their platform (mmap,
named pipes, unnamed pipes, sockets (unix domain, udp, tcp), etc.), not
an IPC mechanism that has historically (at least in Python) been
generally unreliable.

Also, I wouldn't be surprised if the majority of signals are from the
set: SIGHUP, SIGTERM, SIGKILL, none of which should be coming in at a
high rate.


 - Josiah