> > 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 > g_main_context_wakeup().
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. Fredderic _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
