Subj : Re: Threads and signals
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Wed Jan 26 2005 03:29 am

Steve Watt wrote:

> In article <87sm54jeye.fsf@qrnik.zagroda>,
> Marcin 'Qrczak' Kowalczyk  <qrczak@knm.org.pl> wrote:
>>When a signal is sent to a process by kill(), or is generated by
>>setitimer(), which thread handles it?
> 
> Whatever thread is most inconvenient.  Per POSIX, any thread in the
> process (that has the signal unmasked) can receive the signal.  It's
> not unusual for implementors to be lazy, however, and deliver it to
> the thread that ran main(), if that thread is still around.
> 
> Older Linux distributions, without NPTL, often did this, and other
> wrong things related to signals and threads.
> 
>>sigprocmask must be used only in single-threaded programs, right?
>>But pthread_sigmask brings a dependency on pthreads. Does it mean
>>that it's impossible to write code which blocks signals temporarily,
>>doesn't create a dependency on pthreads, but if it's linked with
>>another library which uses pthreads then they still work?
> 

> If you don't create threads, use sigprocmask.  If one of the libraries
> you're calling creates threads and expects those threads to do useful
> things with respect to signals, your sigprocmask should still work OK.

No, it is not guaranteed to work at all. 

Yes, pthread_sigmask brings in a dependency to pthreads... but you don't
need your WHOLE project to be dependent of it.

I.e. you may have a pthread_dep.so module which is the only one linked to
pthread.

in your program do:

if ( ! have_thread ) {
  sigprocmask(...);
  // install your handler etc.
}
else {
  dlopen( pthread_dep.so )
}

OR, you may have
lib_my_handlers.so
mt_lib_my_handlers.so

the both of them presenting the same interface to the linking app, buy the
second one linked against pthreads, and you may link the one or the other
depending on your needs.  

Gian.

.