Re: [Vala] Problem with Thread, GTK and signals

[Jan Hudec <bulb ucw cz>]

On Tue, Sep 29, 2009 at 18:06:17 +0200, Simon Arnaud wrote:
> 2009/9/29 Jan Hudec <bulb ucw cz>

> OK, so I changed the connect to :
>
>     this.download_list.download_progressed += (klass, item_fraction,
> total_fraction) => {
>       GLib.Idle.add( () => {
>           this.view.item_fraction(item_fraction);
>           this.view.total_fraction(total_fraction);
>           return false;
>           }
>           );
>     };
>
> Souns better ? At least, it seems to never stop, unless I resize the
> window.

It should be OK. I would however do it the other way 'round, that is wrap the
emission in GLib.Idle.add. That way the listeners don't have to do anything,
because the signal is always emited in the main thread.

You say it stops working when you resize the window? That would be strange.
Can you verify the idle handler is being both scheduled and dispatched (by
putting in a trace or something)?

> > Another note: GLib, GIO and GTK are designed so that you should not need to
> > use threads. The async functions in GIO allow you to do all filesystem and
> > network access from the event loop and since vala has support for async
> > functions, using the async GIO functions is now easy. Consider using that
> > instead of threads, it will make your life easier. Glib may actually
> > internally use threads for the operations, but you don't have to care about
> > the synchronization that way.
>
> I will try async GIO for this particular case.
>
> However, the main point was to experiment Threads and GTK, with Threads
> doing long lasting tasks and GTK showing the progress. Here, I have network
> downloads, but it could have been long computations, like transcoding audio
> or video.
>
> So, I am trying to see how I can cleanly separate each part, and it seemed
> to me that emitting signals in the Thread, and connect it in a controller
> would be best, as the GUI could be done in various toolkit (GTK, curses,
> cli, whatever).
>
> I might be stupid though to do such things :), and it should be done in a
> completly different way.

Both approaches have their advantages and disadvantages.

Threads are better for things that either use their full CPU slice
(computations) or things that are likely to cause many page faults (like
heavy local file IO, especially mmapped, because you can't explicitly wait
for it). On the other hand they should better be almost independent,
otherwise the synchronization will be pain and slow things down a lot.

Event loop is better for things that involve a lot of waiting (like network
IO), because the event loop can handle that efficiently and you don't have to
bother with synchronization.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>