Re: Signal handlers - please help to understand

[Chris Vine <chris cvine freeserve co uk>]

On Wednesday 22 December 2004 11:19, Igor Gorbounov wrote:

[snip]

> In manuals about system signals (SIGALRM, SIGIO...,SIGRTMIN...) is said
> that signal
> handlers for them should not execute any usefull code, they are intended
> to set some flag
> only. It's a recommended way to use them.
> So I'm trying to solve this problem (because I need a lot to do when
> those system signals
> arrive) by using sigc::signals to deliver received data for example. It
> seems to work but
> I'm not shure that I'm going in a proper way so this is why I ask about
> it all here because
> I don't quite understand how those (late) slots are working.
>     Thanks for answering,
>        Igor Gorbounov

As others have pointed out, Unix signals and libsigc++ signals/slots are 
entirely different things, which unfortunately share a common name.  Unix 
signals are asynchronous - they are software interrupts (generally but not 
universally maskable) - and you should only call async-signal-safe functions 
in them.  Generally the less you do in an asynchronous Unix signal handler 
the better: a good rule of thumb is only to set flags, which should be of 
type volatile sig_atomic_t.  Unix signals are a mechanism by which single 
threaded programs can respond to system or other outside events, and they 
execute in the thread of execution of the interrupted thread (the main 
process in the case of a single-threaded program)[1].

libsigc++ signals/slots on the other hand are just a convenient interface for 
callbacks: an intelligent functor if you will.  It would generally be a 
mistake to call a libsigc++ signal in a Unix signal handler, as it will be 
executing the slot(s) connected to the signal asynchronously (that is, 
outside the normal synchronous flow of program execution).

Chris

[1] Nowadays the best way to deal with system signals is to mask off all those 
of interest, and then to start a separate signal handling thread which calls 
sigwait(), and then deal with any signals received in that thread (where the 
signals will be synchronous for that thread).  If the signal handling thread 
needs to communicate with another thread, it can do so with Glib::Dispatcher.  
It is safe to use thread safe functions and/or mutexes in such a signal 
handling thread.  It is extremely unsafe to use mutexes in an asynchronous 
signal handler.  Unfortunately Linuxthreads have a number of deficiencies 
which mean that this strategy will not work with the SIGCHLD signal.  If you 
want to discuss how asynchronous signals interract with multi-threaded 
programs with Linuxthreads (it is problematic but soluble), and for that 
matter in POSIX conforming threads, please e-mail me off the mailing list.  I 
know nothing about Windows threads.