Re: Handling Unix signals in a GTK+ application

Add a unix signal number in the signal handler, and suck it out
again in a custom event source's prepare method. The prepare
method can return -1 for its timeout contribution, and true/false
if there's something in the queue.
So... poll *will* exit because of the signal... but will it check
its event sources and everything... if no file descriptor is ready
and timeout isnt reached ?  you'll have to test it out with an idle
main loop... because for the same reasons... you cant call

I'll have to check the Glib source when I get back in about three weeks time...  If I remember (the 
discussion will probably be well and truely over by then...  heh).

It SHOULD do the checks, as long as the main loop does a full cycle when it gets an EAGAIN from poll(), and 
doesn't just skip right back into the poll() call (which I personally think would be a very bad design idea). 
 Returning -1 as the timeout basically tells the main loop to wait indefinately in the poll() call (unless a 
different event source, such as a timeout or idle, tells it to finish sooner).

The source prepare methods, as I understand from the documentation, are the part that really drives the whole 
thing.  They prepare the list of file descriptors that are passed to poll(), and it's the prepare methods 
that set up the timeout value that will be given to poll().

The event sources that indicated that there was an event waiting are then given a chance to dispatch those 
events after the poll() call.

So it's sort of like an idler in that it'll get called every time through the loop (in fact, it should get 
called EVERY time though the loop, unlike an idler), but it's different from an idler in that it won't cause 
the poll() call to exit prematurely, and hence you won't get a busy wait happening.


Join Excite! -
The most personalized portal on the Web!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]