Re: About Treeview update with thread

[muppet <scott asofyet org>]

On May 9, 2009, at 8:38 PM, 唐瑞博 wrote:

> hi, muppet
>
> many thanks for your reply and your suggestions.
>
> - Remember to grab and release the gdk lock around the gui accesses  
> from the other thread, or
>
>   Do you mean use Gtk2::Gdk::Threads->enter and Gtk2::Gdk::Threads- 
> >leave when i update the treeview?

Yes.

> I have run the changed code, but it is no better, the same problem  
> aslo exist.  Is there any  thing missed when i grab and release the  
> gdk lock use Gtk2::Gdk::Threads->enter/leave.

The snippets you provided previously don't show much surrounding  
context, so it's only a guess.   :-/


> - Instead of immediately modifying the treemodel in your background  
> thread, install a single-shot idle that will do it.  This  
> effectively defers the work to the main thread so that only one  
> thread touches the ui.
>
> For this suggestion, do you mean I use a Gtk2::Idle->add(sub {  })  
> in the main thread, and in this function to update the Treeview.
> But how the main thread to know which row should be updated?
> or to loop each row to update the whole treeview, but there exist  
> efficiency issues.

The call to Glib::Idle->add(...) would be on the background thread,  
not the main thread.  The callback will then be executed by the thread  
running the main loop (the main thread).  This is a common idiom in  
other gtk+ environments.

To ensure that the callback knows what to do, you would simply collect  
the information before the call to idle add, and pass it along.  From  
the snipped posted above, it looks like everything you need is  
accessible via the $tid...

      # defer update to main loop's thread
      Glib::Idle->add (\&update_treeview, $tid);


A variant of this technique is to have the main thread listen for  
information on a pipe, and have the worker thread spit its results  
back over the pipe.  This is the same thing you'd do if you forked  
your worker to another process, and is, in fact, the method i  
typically use.  (I find that threads in perl are usually more trouble  
than they're worth, provided you can get around them.)


If you can provide a small but complete simulation of your environment  
that still exhibits the problem, then we can get out of abstract  
suggestions and into concrete solutions.


--
Yvonne: Let's do that one again so i can win.
Zella: No.