From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-09-13 16:02:29
Carlo Wood wrote:
> If not, then I think direct support for this has to be added.
> A signal handler can be called at almost any moment in the code
> and can therefore not use system resources, or shared resources,
> of any kind. You can't even have it wait for a mutex. Basically
> all a signal handler can do is set an atomic flag that there has
> been a signal.
The trouble here is that you lose information if two signals arrive
back-to-back (which unfortunately POSIX allows the implementation to
lose anyway, but that doesn't mean you can be as lazy as the laziest
implementation!) Also, some signals will not interrupt select() on some
POSIX-compliant UNIXes. I searched long and hard for a perfect generic
signal handler, and unfortunately, concluded there was no such thing.
The best implementation I came up with was using an atomic add to
increment a counter in a table of signals, and then writing to a pipe
(which can also be used as a hint) to signal select(). Specific
operating systems, such as Linux, will still require something more to
decode extra information within exceptions.
Aaron W. LaFramboise
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk