Re: [gtk-list] Forking

[Tim Janik <timj gtk org>]

On Sat, 19 Dec 1998 lev@mindless.com wrote:

> 
> Hello allmighty all,
> 
> I am writeing a program and I want some operation to be per performed w/o
> stopping gtk (network talk). I fork the program and the child sends
> signals to notify the parent. Now the qestion is, is it ok to call gtk
> functions from signal handler? Signal may be called while gtk_main is
> doing what ever it was to do. Is it bad to interrupt it and do other
> gtk stuff? Is there a better way to organize this?

yes, calling gtk (or gdk or glib) functions from signal handlers is a bad idea,
since there's no way to asure that the code portion gtk is currently in is
fully reentrant, and it's actually very likely that it is not.

currently, there exists no better way then using a static variable that
indicates whether a signal occoured (the signal handler shouldn't do
anything more than setting that variable), and then periodically check that
variable from e.g. a gtk timeout function.

we should at some point implement something along the lines of
guint           g_signal_add_full       (gint           priority,
                                         guchar         signal,
                                         GSourceFunc    function,
                                         gpointer       data,
                                         GDestroyNotify destroy);
void            g_signal_notify         (guchar         signal);

you'd then hook up callbacks for signals with g_signal_add_full() and
from within your signal handler, you'd just call g_signal_notify(sig).
the callbacks will then be handled from the gtk (glib) main loop and
get executed after the signal handler returned.

> 
>   - Lev
> 

---
ciaoTJ