Re: Query about handling OS signals

[Andreas Stricker <andreas stricker fela ch>]

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.

> If not, it looks as if the only standard way is to have the OS
> signal-catching routine just turn on "had_a_signal" and use
> g_timeout_add to call a function which looks at "had_a_signal". Or is
> there a better way?

This is a common solution and may may be sufficient for some cases.
But this has two downsides:
* You may miss some signals (two signals occurred between check
  for the flag)
* You have to poll the variable.

> Or is there is some altogether better way of doing all this that I
> haven't thought of? Please note rewriting the daemon process is not
> currently an option.

If the flag variable is not sufficient, you may use an unnamed pipe
to fill with signals from signal handler on one side and add it as
GIOSource to glib main loop. Now you won't miss any signals and
the main loop returns immediately if a signal occurred.

A while ago I wrote some code to do this:
http://www.knitter.ch/src/gunixsignal/

Cheers, Andy