|
Q: I have a multi-threaded process on Mac OS X. If
my process receives a signal, which thread executes the
signal handler?
A: Synchronous signals, those caused by the thread
itself (like SIGPIPE and SIGBUS),
are delivered to the thread that caused them. Asynchronous
signals (signals sent to the process by an external source)
are delivered to an arbitrary thread within the process.
|
IMPORTANT:
At the time of writing, Mac OS X
chooses the thread to execute
asynchronous signal handlers using the following
criteria.
- The thread must still
be running (that is, not
terminated).
- On Mac OS X 10.2 and
later, the thread must not have the signal
masked (using
pthread_sigmask).
- An older thread is
preferred to newer thread.
Thus an asynchronous
signal is sent to the oldest non-terminated thread
that does not have it masked. Do not rely on
this exact behaviour.
The thread chosen to handle an asynchronous signal
is not guaranteed (except in the case of
pthread_kill, described below)
and could change an future
systems.
|
Q: I have a multi-threaded process on Mac OS X. If
one thread receives a signal, will the other threads
stop?
A: No. All other threads continue to run during
signal handler invocation.
Q: Has there been any change in thread signal
handling in Mac OS X 10.2?
A: The above answers still hold. The most
significant changes in thread signal handling in Mac OS X
10.2 are that you can now send an asynchronous signal to a
specific thread within your process
(pthread_kill), set a per-thread signal mask
(pthread_sigmask), and wait for a specific
signal (sigwait).
Q: If one of my threads is
waiting in sigwait, is it guaranteed to be the
thread that executes an asynchronous signal
handler?
A: No. The choice of thread
to execute an asynchronous signal handler is described
above, and it is not affected by calls to
sigwait. This is in line with POSIX standard.
The only way to guarantee that a specific thread will handle
an asynchronous signal is to mask that signal in all other
threads.
[Aug 27 2002]
|