Re: Heavy IOChannel use starves UI painting

["Matt Hoosier" <mwhoosier gmail com>]

On 5/28/06, Paul Davis <paul linuxaudiosystems com> wrote:
> 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,

Agreed. But in this example, the IO handlers do return at least once
for every 32K chunk of data copied. For a file with even just 10 MB of
content, that's hundreds of iterations of the mainloop: chances (one
would think) for the UI to repaint itself. During those hundreds of
mainloop iterations, the progressbar widget is getting put into a
dirty state ~100 times. How does one judge when the painting logic
will take notice of this dirty flag and decide to issue an expose
event?

> 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).

Well, my arguments above notwithstanding, I'd have to agree with you
given the empirics here.

Thanks.

> --p