"Adam Olsen" <[EMAIL PROTECTED]> wrote: > > 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. [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 _______________________________________________ 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
