Re: watching a file descriptor in gtk3

[rbd <rbd soest hawaii edu>]

Thanks for all the further explication, Chris!

> The problem is that the main loop would enter a busy loop.  Well, maybe
> a 'busy-ish' loop.  If you call up g_idle_add() with a repeating
> callback (one which returns TRUE) which does nothing except examine a
> non-blocking select(), you will end up with one CPU core using
> approximately 100% CPU.  The default idle priority
> G_PRIORITY_DEFAULT_IDLE will put the idle event somewhat at the end of
> the main loop's event queue, but when there is nothing else to do it
> will continue executing it.  (On a multi-core system this might not be
> immediately apparent - you need to be able to interpret top or whatever
> other tool you use to see it.)
>
> You could make this work with a timeout, say of around 50mS delay,
> which puts the main loop to sleep for a while between iterations.

I hear you about the busyloop/timeout stuff. I have some familiarity with 
these issues from the ancient Xlib (and single-core/-CPU!) days, and 
appreciate your insight into how this impacts the glib/gtk mainloop.

> It is not quite that bad.  The documentation for g_source_add_unix_fd()
> is inadequate, but although not immediately obvious the prepare, check
> and finalize handlers can in fact usually just be set to NULL (provided
> you have set the 'events' argument for g_source_add_unix_fd()
> correctly) so you only need to provide the dispatch handler, which
> executes your callback when an event occurs.
>
> The poor quality of the documentation is the real problem here.  I
> would give it a try and see how you get on with it.

Nothing about the g_source_* functions is obvious from the official docs, 
either immediately or otherwise! ;-> Seriously, one of the least 
illuminated points there actually has to do with timeouts, exactly where 
in the check->prepare->dispatch sequence the poll() gets done, etc.

> The GIOChannel interface is not well designed by today's standards.  It
> confuses concerns by combining a wrapper for poll() with an object for
> locale-based reading to and writing from files.  It is against modern
> design practice to combine purposes in this way.  But it is old (it goes
> back to GTK+-1.2 days) when large multi-purpose objects were all the
> rage. We know better now.
>
> Its naming is also now highly confusing as it is not related to glib's
> gio namespace, which also provides numerous i/o functions, with an
> emphasis on asynchronicity (but which unfortunately suffers from an
> overly java-like approach to its stream objects - it may also be a
> victim of its times).

Interesting history. Mixed-purpose utilities are a bit off-putting, but 
reliability and amount of available, easily understandable documentation 
go quite a long ways towards putting them back on again! My input is 
binary so I'd be turning off the encoding (and probably buffering) stuff 
anyway.

Thanks again for all your help!

Roger