3 Jun
2008
3 Jun
'08
10:50 a.m.
On Tue, 2008-06-03 at 14:15 +0200, Tim Goetze wrote:
[Fons Adriaensen]
and as an example, the Quartz (OS X) backend for GTK uses this because
it has to wait for events on file descriptors and from Cocoa/Quartz
(equivalent to X11).
sadly, it still ends up using one thread to wait on file descriptors and
this thread "injects" a Cocoa-level event into the other "main" event
thread. this is because OS X, like almost all Unix systems, fails to
provide a single system call to "wait till something happens". you
cannot wait for a file descriptor, semaphore, msgqueue, X event and/or
whatever else with a single blocking system call, and IMHO this is still
one the biggest weaknesses of the POSIX API.
I don't know the details of GTK, but this is a
classic problem
with high-level GUI toolsets: they don't allow you to wait
for X events (which trigger the loop, behind the scenes) and
anyhting else at the same time in the same thread. They don't
even separate _waiting_ for an X event, and _handling_ it into
two separate user calls (which would allow the user to add the
missing multiple wait functionality). This is one of the
reasons why I wrote my own GUI toolkit.
You should check out g_main_context_set_poll_func() sometime. I admit
it took me longer than it should have to find it myself. In short, it
does what you want. In a gtk way, sure, but it does it.