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

Adam Olsen rhamph at gmail.com
Tue Sep 12 08:59:58 CEST 2006

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.
> If we get too paranoid about this, we'll just end
> up deciding that signals can't be used for anything,
> at all, ever. That doesn't seem very helpful,
> although techically I suppose it would solve
> the problem. :-)
> My own conclusion from all this is that if you
> can't rely on writing to a variable in one part
> of your program and reading it back in another,
> then computer architectures have become far
> too clever for their own good. :-(

They've been that way for a long, long time.  The irony is that x86 is
immensely stupid in this regard, and as a result most programmers
remain unaware of it.

Other architectures have much more interesting read/write and cache
reordering semantics, and the code is certainly broken there.  C
leaves it undefined with good reason.

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.

Hmm, if that works we should be able to generalize it for all the
other flags too.  Something to think about anyway...

Adam Olsen, aka Rhamphoryncus

More information about the Python-Dev mailing list