Mike - EMAIL IGNORED wrote:
You might be better off asking in a Posix newsgroup.
You're probably right, but there are two C++ questions hidden in
there. The answer to the first is, of course, he can only call
these functions from C++ if the system has taken the necessary
steps so that they will show up as `extern "C"' when included
from a C++ program. (All the systems I know have, but you never
know.) The answer to the second is a bit more direct: according
to the C standard (and this part of the C standard has been
explicitly included by reference in the C++ standard): "If the
signal occurs other than as the result of calling the abort or
raise function, the behavior is undefined if the signal handler
refers to any object with static storage duration other than by
assigning a value to an object declared as volatile
sig_atomic_t, or the signal handler calls any function in the
standard library other than the abort function, or the signal
function with the first argument equal to the signal number
corresponding to the signal that caused the invocation of the
handler." Of course, an implementation may define any undefined
behavior, and Posix does, in fact, define a few additional
things you can do in a signal handler.
There's also a more general programming question involved, more
appropriate to comp.threads than any system specific group. But
the answer is obvious: any attempt to lock a mutex (or acquire a
semaphore, or anything else) from an asynchronous signal
guarantees a potential deadlock. (FWIW: under Posix, you do not
normally use signal handlers in multithreaded code. Posix has
other ways of handling this, that do, or at least can be made to
work.)
