Dan Sugalski <[EMAIL PROTECTED]> wrote: >>I know that. The current scheme is safe WRT these problems. A signal >>originates from the signal handler, incrementing a sig_atomic_t variable >>per signal.
> That doesn't work. ??? It's one of the few safe actions what you can do in an interrupt handler. WTF should that not work. > ...Besides requiring an aligned atomic word per > interrupt source, it requires something to scan those words Why aligned? If you can't set a sig_atomic_t var in a signal handler and test that outside, you are hosed anyway. What is the problem with that? How do you do it? The io_thread wakes up on EINTR and tests the sig_atomic_t sighup or such, what's wrong? > That's pretty horribly platform-dependent. Of course. I did describe signals. They are platform-dependent. Win32 don't have much (and no usable) signals at all. This scheme is for unixish plaftforms. Win32 will have a different one. OS X maybe too. This is an implementation of events on a specific platform. The whole event system is platform-dependent in the guts. >>There's always a choice. Please have a look at the current code. > I have. It's fundamentally broken pretty much everywhere. We just > don't trigger off the broken behaviour yet. This "pretty much everywhere" is e.g.: Thanks for your detailed analysis. leo
