> The fun part about async vs sync is there's no common decision on what's an > async signal and what's a sync signal. :( SIGPIPE, for example, is one of > those. (Tru64, at least, treats it differently than Solaris) > > I generally divide signals into two groups: > > *) Messages from outside (i.e. SIGHUP) > *) Indicators of Horrific Failure (i.e. SIGBUS)
I think the another (*better*) way for this is "process-wide signa" vs "thread-specific signal". > Generally speaking, parrot should probably just up and die for the first > type, and turn the second into events. Have you reversed the ordering??? How can you convert SIGBUS to events? > AFAIK, almost none of the pthread functions are safe in signal handlers. > There might be one or two, but I can't remember which ones. (None of the > mutex or condition functions, alas, and they're rather useful) Keep this for record. sem_post() is the only signal-safe thread function. I don't think mutex and condvar are useful in this case. If > >We create one thread for all async signal, and let everyone else mask async > >signal off. This scheme can handle signal reliably under threads. > > This, unfortunately, isn't portable. It only works on platforms that fully > implement the POSIX threading standard. Linux is the big example of a > platform that *doesn't*. Signals only get delivered to the thread that > triggered them, and if the thread's got the signal masked off it gets > dropped. :( You did not get my idea. I was talking about async (message from outside, process-wide signal). There is no notion of "the thread that triggered them" here, which is about sync signal only. Linux does have sigtimedwait() etc. The mask off has different defs. You can set it SIG_IGN which drop the signal. Or you can use sigmask() to mask it off, and signal will be enqueued. Hong
