| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 13-MAR-1997 15:31:27.53
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: RE: FWD: Threads and Signal
Hello Hu Rui,
>Is there any thread based signals.
>
>I am making multi threads database server, each thread handle one
>connection. The connection is TCP socket. The socket I/O functions use
>signals SIGALRM, SIGPIPE. When signal comes, I do not know which thread
>should response it.
>
>So I wonder is there any thread based signal?
>
Here are some extracts from the documentation relating to this issue. Does
this help?
================================================================================
From "Guide to DECthreads" manual, part of D/UNIX v4 docs
A.5 Using Signals
This section discusses POSIX 1003.1c-1995 signal handling.
Digital UNIX Version 4.0 introduces the full POSIX 1003.1c-1995 signal model.
In previous versions, "synchronous" signals (those resulting from execution
errors, such as SIGSEGV and SIGILL) could have different signal actions for
each thread. Prior to Digital UNIX Version 3.2, all threads shared a common
process-wide signal mask, which meant one thread could not receive a signal
while another had the signal blocked.
For Digital UNIX Version 4.0, all signal actions are process-wide. That is,
when any thread uses sigaction or equivalent to set a signal handler, or to
modify the signal action (e.g., to ignore a signal), that action will affect
all threads. Each thread has a private signal mask, so that it can block
signals without affecting the behavior of other threads.
Prior to Digital UNIX Version 4.0, asynchronous signals were processed only in
the main thread. In Digital UNIX Version 4.0, any thread that doesn't have the
signal masked may process the signal. For binary compatibility, threads created
using the cma or 1003.4a Draft 4 interfaces begin with all asynchronous signals
blocked.
A.5.1 POSIX sigwait Service
The POSIX 1003.1c sigwait service allows any thread to block until one of a
specified set of signals is delivered. A thread can wait for any of the
asynchronous signals except for SIGKILL and SIGSTOP.
For example, you can create a thread that blocks on a sigwait() routine for
SIGINT, rather than handling a Ctrl/C in the normal way. This thread could then
cancel other threads to cause the program to shut down the current activities.
Following are two reasons for avoiding signals:
Signals cannot be used in a modular way in a multithreaded program.
Signals, used as an asynchronous programming technique, are unnecessary
in a multithreaded program.
In a multithreaded program, signal handlers cannot be used in a modular way
because there is only one signal handler routine for all of the threads in an
application. If two threads install different signal handlers for the signal,
all threads will dispatch to the last handler when they receive the signal.
Most applications should avoid using asynchronous programming techniques in
conjunction with threads. Techniques relying on timer and I/O signals, for
example, are usually more complicated and error-prone than simply waiting
synchronously within a thread. Furthermore, most of the threads services are
not supported for use in signal handlers, and most run-time library functions
cannot be used reliably inside a signal handler.
Some I/O intensive code may benefit from asynchronous I/O, but these programs
will generally be more difficult to write and maintain than "pure" threaded
code.
A thread should not wait for a synchronous signal. This is because synchronous
signals are the result of an error during the execution of a thread, and if the
thread is waiting for a signal, then it is not executing. Therefore, a
synchronous signal cannot occur for a particular thread while it is waiting,
and the thread will wait forever.
POSIX requires that the thread block the signals for which it will wait before
calling sigwait.
A.5.2 Handling Signals as Exceptions
For the signals traditionally representing synchronous errors in the program,
DECthreads catches the signal and converts it into an equivalent exception.
This exception is then propagated up the call stack in the current thread and
can be caught and handled using the normal exception catching mechanisms.
The following table lists UNIX signals that are reported as DECthreads
exceptions by default. If any thread declares an action for one of these
signals (using sigaction(2) or equivalent), no thread in the process can
receive the exception.
Table A-3 Signals Reported as Exceptions
Signal Exception
SIGILL pthread_exc_illinstr_e
SIGIOT pthread_exc_SIGIOT_e
SIGEMT pthread_exc_SIGEMT_e
SIGFPE pthread_exc_aritherr_e
SIGBUS pthread_exc_illaddr_e
SIGSEGV pthread_exc_illaddr_e
SIGSYS pthread_exc_SIGSYS_e
SIGPIPE pthread_exc_SIGPIPE_e
|