Re: Heavy IOChannel use starves UI painting

[Paul Davis <paul linuxaudiosystems com>]

On Sun, 2006-05-28 at 14:00 -0500, Matt Hoosier wrote:
> Hi,
> 
> I wrote a little application on top of the Glibmm frontend to
> GIOChannels which displays a progressbar while a file is copied.
> 
> When the channels are constantly available for reading and writing
> (and thus their callbacks are always being executed), though, the UI
> becomes totally unresponsive. This is a little perplexing to me, since
> a stated purpose of using GIOChannels is to integrate IO into the
> mainloop so that the UI stays snappy.

not quite.

its to make it *possible* to integrate IO into the mainloop. the
mainloop's primary purpose is still to handle and dispatch events, and
if your file i/o code is stopping the mainloop from doing that in a
timely fashion, then its interfering with that purpose. the mainloop
calls your io callbacks and doesn't regain program control to handle
events until they return, which is going to be slow if they are doing
large scale disk i/o (or even any disk i/o, actually).

> Have I got the wrong paradigm in mind? That is, should one expect that
> constant execution of the iochannel handlers will starve execution of
> the UI drawing inside the mainloop's thread? Source is attached. The

yes, you can totally starve the UI if you choose to.

if you want good i/o throughput and a snappy UI, you have no choice but
you use threads. doing everything from the main loop means you have to
compromise one of those two goals (or even both of them).

--p