Re: [gtk-list] Handling OS signals?

[Joshua Richardson <jric bu edu>]

Posix semaphores can be used with aync signals.  The sem_post operation is
async safe on many implementations.  If on yours, then you could sleep
your main thread.  In your signal handler, you could set a function
variable to the callback you wanted, then do a sem_post operation.  Your
main thread would wake up, and then it could set the callback, etc.  That
way you could leave all your Gtk calls in your main thread.  Right?

Here's a piece of my Linux man page for sem_wait:

ASYNC-SIGNAL SAFETY
       On processors supporting  atomic  compare-and-swap  (Intel
       486,  Pentium and later, Alpha, PowerPC, MIPS II, Motorola
       68k), the sem_post function is async-signal safe  and  can
       therefore be called from signal handlers. This is the only
       thread synchronization function provided by POSIX  threads
       that is async-signal safe.

       On  the  Intel 386 and the Sparc, the current LinuxThreads
       implementation of sem_post is  not  async-signal  safe  by
       lack of the required atomic operations.


----------------------------------------------------------------
                       Joshua Richardson
Dept. Cognitive and Neural Systems / Center for Adaptive Systems
                       Boston University
----------------------------------------------------------------

On Thu, 18 Feb 1999, Drazen Kacar wrote:

> I have an application that forks off several child processes and then sleeps
> most of the time, but it should show how many children exist at a given time.
> I can receive SIGCHLD when a child exits, but I don't know of an elegant
> way to tell GTK that I want my function called after the signal handler
> returns.
> 
> GTK sleeps in GLib's poll() and any OS signal will invoke my signal handler
> and then interrupt poll(). GLib will then look if there are events to be
> dispatched and if none found, return to poll(). I could do processing in
> OS signal handler, but that's not advisable, since most OS functions
> are not guaranteed to be async safe. So I'd like to set a variable or two,
> register one callback and return. Upon return, GLib should invoke that
> callback to do the actual job. The problem is that I don't know which
> (if any) function for callback registration is reentrant and safe to call
> from an OS signal handler.
> 
> I could use timers or something, but that's ugly and inefficient.
> 
> -- 
>  .-.   .-.    Life is a sexually transmitted disease.
> (_  \ /  _)
>      |        dave@srce.hr
>      |        dave@fly.cc.fer.hr
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 
>