Re: Gtkmm Threads question.



On Tue, 12 Jan 2010 16:49:34 +0000
Filipe Apostolo <f apostolo cbr gmail com> wrote:
> Hello,
> happy new year to everyone.
> 
> I have created a GUI with a treeview, each row of the treeview
> represents a system with its own calculations and results.
> Each referred system must  do its calculation in simultaneously, so I
> launch a thread (Glib::Thread ) to run each system.
> This is working fine and I'm getting the desired result/behavior.
> 
> However I want to display the calculated value of each system in the
> treeview at already created column named "value".
> 
> 
> I had read that only the main thread is allowed to change widget
> values. So I must to send the calculated value to the main thread
> which will identify the sender system and update the value field of
> this system in the treeview.But I'm not reaching the solution for
> this.
> 
> I read about the Glib::Dispatcher and have implemented and I'm
> connecting  the signal to the handler with success but I cant pass the
> calculated value through it. And I cant also  make something like:
> "system[sender_id]->GetValue () " inside the Handler,  because this
> object is in a loop function (Run()) so the program will crash if the
> try to access the GetValue.
> 
> This is simple SingleConsummer (main thread) and multiple producers
> (each system thread) configuration.
> 
> I'm working in WindowsXP OS, so I think that I cant use Tunnel like
> in Unix;
> 
> What do you suggest me to do? Use Dispatcher, use simple
> sigc::signal<void,double> to pass the parameters, what does your
> experience tell you?

Don't use libsigc++ for this as it is not thread safe (unless you know
what you are doing).  For a multiple producers and single consumer
arrangement the best choice is to put the values in an asynchronous
queue for the consumer to pick up when Glib::Dispatcher emits.

glibmm does not have an asynchronous queue, and if you don't have your
own one to hand I can e-mail you one I use if you want (there are some
design wrinkles involved if you want strong exception safety as well as
thread safety). There was also a bug posted a couple of years ago by a
user proposing an asynchronous queue for inclusion in glibmm and
submitting a proposal. It wasn't included, but you can pick that up from
gnome bugzilla if you want.  The final version of it looked reasonably
workable.

Chris




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]