Re: Handling Unix signals in a GTK+ application

[Thomas Okken <thomas_okken yahoo com>]

Gus Koppel wrote:

> However, if you know your application belongs to the
> majority of GTK+ applications, that is, it stays in
the
> outermost main loop, spending most of its time
actually
> being idle, then using the idle handler may  be
> appropriate. But as explained, it's not quite as
> "fail-safe" as pipes.

My application is scriptable, so while it's running a
script, an idle handler would never get invoked... Not
that that's such a problem, because it would be easy
enough to insert a check for an "interrupted" flag in
the script interpreter's main loop. My concern is what
happens when the application actually *is* idle. Using
an idle handler does not prevent you from having to
busy-wait in that case, it just means you're using a
fancy mechanism to do it; you still have to make the
compromise between fast response (by having an idle
handler that basically sucks up all free CPU cycles)
or being multitask-friendly (by using a timer so you
only check every second, say). The big plus of the
pipe approach is you get the best of both.

<soapbox>I think GTK+ really should have its
XtNoticeSignal() equivalent. It's a strange omission,
IMHO -- but I guess it keeps falling through the
cracks because it's not too difficult to work around.</soapbox>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com