Re: Query about handling OS signals

["Andrew W. Nosenko" <andrew w nosenko gmail com>]

On Thu, Apr 10, 2008 at 2:51 PM, Andreas Stricker
<andreas stricker fela ch> wrote:
> John M Collins schrieb:
>
> > The signals are sent by the daemon process to tell the receiving clients
>  > "you might want to refresh your display". It is for the receiving
>  > clients to worry about whether they do need to refresh their displays
>  > (the actual data is in shared memory).
>  >
>  > My first question is: Is it safe to emit a signal (i.e. the GTK idea of
>  > a signal) within the OS-signal handling routine?
>
>  AFAIK this is still not save. You should not call any glib/GTK functions
>  from within a signal handler.

Yet another reason "why not": emiting of signal (GObject signal)
results in the immediate execution of the signal callbacks.  GObject
signals are sinchronious (not queued).  Therefore, from the program's
point of view, you will have unpredictable amount of the functions,
which execute unpredictable code and take unpredicatable amount of
time, called from the OS-signal handler that is very bad idea in
general.

P.S.  GObject gurus: please, correct me if I'm wrong and exists some
way to emit/handle GObject signals in the asynchronious way
(queued/fetched/executed/multiplexed through GMainLoop).

-- 
Andrew W. Nosenko <andrew w nosenko gmail com>