Re: About Treeview update with thread

[唐瑞博 <ruibotang gmail com>]

hi, muppet,

 

Many thanks for your suggestion, sorry for late to response. 

 

I have tried the three methods you mentioned (gdk lock; Glib::Idle  and a variant technique), and found an alternative solution for my issue.  But there still exist other unsolved issues, as below

 

For the gdk lock method, I have used Gtk2::Gdk::Threads->enter and Gtk2::Gdk::Threads->leave in my background thread, it seem that it can update all the widgets(like button, labes) correctly excepte the Gtk2::TreeModel(I used a Gtk2::ListStore actually).  when i use the Gtk2::TreeModel->set() method, it will fail and says "Usage: Gtk2::TreeModel->set($liststore, $iter, $col.....)" , and then the exit.   I checked my code and found that I have a column with type Glib::Scalar in my treemodel, in this column i assign a pointer to an new constructed object ( the object is not a subclass of Glib::Object, and have not decleared as shared), I do not know if the fail have relationship with this object?

 

For the Glib::Idle method method, I put Glib::Idle->add (\&update_treeview, $tid)  to my background thread, and it appear the same error as first method.  According to your reply, i think the update_treeview  should be run in the Main thread, but after my check, i found it runs in the background thread actually, so when the background thread access the Gtk2::TreeModel->set, it will fail as the first method. 

 

For the third method, i used a Thread::Queue as pipe, the background thread enqueue the need updated data to the pipe, in my main thread, i use Glib::Timeout->add(1000, \$update_treeview)  to update my GUI, every 1 second will to update the GUI,  in this method I access the Gtk2::TreeModel->set in the Main thread, so the error does not appears. And all works well.  Although update UI is not realtime, also can acceptable.  I do not know if there are any better solutions for my issue or if there is any improvement for this method?    

 

Anyway the third method can be an alternative solution for my issue, and thank you very much for all your kindly help!

 

Ruibo

2009/5/10 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.

-- 
Best Regards

Tang Ruibo（唐瑞博）
===============================
Beijing University of Posts and Telecommunications

E-mail:  ruibotang gmail com
T e l :    (86)10-62283926