On 9/12/06, Greg Ewing <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
