Subj : Re: nptl and signals
To   : comp.programming.threads
From : Chris Vine
Date : Wed Jul 27 2005 12:05 pm

divijbhatt@gmail.com wrote:
[snip] 
> Hi,
>     Chris I have seen that link instead I have put the pthread_sigmask
> before creating the threads but my program blocks.So, I put them after
> creating the threads where I am checking the flags just before that.
> I think there is some problem with design also but tell me I am using
> sigwait for blocked signals when those signals will be dilevered to the
> calling thread then signal handler function willn't be executed? I am
> making the flag 1 in that signal handler function that's why I need
> that function to be worked upon.

No, what you are doing is wrong.  You either block all signals in the
threads of execution in the process of concern, and then have a single
signal handling thread in that process (for which the signals of interest
are ALSO blocked) which enters a blocking wait using sigwait(), or you
provide a signal handler for the process.  If you are using sigwait() it is
supposed to block, that is the whole purpose - to provide a dedicated
thread which blocks on sigwait() until a signal has been received.  By
blocking, sigwait() acts as an asynchronous to synchronous converter: the
whole purpose of sigwait() is to handle signals synchronously in one
dedicated thread, rather than handling them as an interrupt asynchronously
in any thread.  You cannot do both.  Handling signals synchronously in one
dedicated thread is much superior because you are not restricted to
async-signal-safe functions only.  You can use any function which is thread
safe (which includes practically all system calls).

In the single threaded days when Unix was developed, then the only way a
system or other "outside" event could be delivered to a running process was
asynchronously.  Signal handlers were the only way to do it. 
Multithreading offers more subtle approaches and in POSIX this is
accomplished by sigwait().

If you decide to deal with signals using a signal handler rather than a
special dedicated thread, the handler can execute in the thread of
execution (ie interrupt any thread of execution) of any thread for which it
is not blocked. POSIX does not specify which.  Generally it does not matter
which thread of execution is interrupted anyway.  It is entirely
asynchronous so you cannot rely on anything thread specific in the handler.

If you are using Linuxthreads instead of NPTL you cannot use sigwait(), and
you will have to provide a signal handler.  With Linuxthreads that handler
will generally only execute in the thread of execution of the thread which
called sigaction(), with nuances (the SIGCHLD signal will only execute in
the thread which called fork()).  You must therefore ensure that the signal
is not blocked to the only thread which will receive it or it will remain
blocked for ever.

In short: if you are using NPTL use sigwait().  If you are using
Linuxthreads provide a signal handler.

Chris.

-- 
To reply by e-mail remove the --nospam-- in the address.

.