Re: Signal handlers - please help to understand

[Paul Davis <paul linuxaudiosystems com>]

>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 

totally wrong concept.

sigc::signals are really nothing more than a very nice callback
system. people talk about signals+slots and so forth, but at the core,
its just a system for attaching a series of function calls plus
arguments to a list and then executing those function calls at some
later point in time.

if you emit a sigc::signal, you are just executing whatever callbacks
are in the list, and doing so from within the function context where
the signal is emitted. so you are not avoiding the restrictions on
what a POSIX signal handler should do.

what you need to do is to set up a FIFO that is hooked into the main
GTK event loop (i don't know the gtkmm functions to do this, but the
glib functions are things like g_io_new(). then in the POSIX signal
handler, write a byte to the FIFO to wakeup/notify the GTK event loop
that something needs to be done. The callback you provide for the
"data ready" condition on the FIFO will be executed, and it can read
the data that SIGIO was telling you about.

a simpler approach if you're not doing true real-time stuff is to
simply stop using SIGIO and plumb the file descriptor that is causing
SIGIO to be sent into the event loop (g_io_channel_unix_new() in
glib), and skip all this mess. the event loop will call your "data
ready" handler when data is available.

please don't send me personal email about this. i will be gone
tomorrow and have way too much to do today to answer detailed
questions about this. send any further questions to the list and
hopefully other people will be able to help you.

--p