Re: Gtkmm Threads question.

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 13 Jan 2010 10:08:20 +0000
Filipe Apostolo <f apostolo cbr gmail com> wrote:
> I'm getting confused here about the Dispatcher, who instantiates the
> dispatcher?
> The main window, or the system class running in the thread? My first
> approach was instantiate a dispatcher in each system thread and when
> the calculations where done I emit the signal which would be caught
> by the window who owns the treeview.
> 
> But in the documentation says that the Dispatcher must be instantiate
> in the Receiver thread. This means that I have to create a
> sigc::signal in the system thread connect it to a Handler in the
> window thread and this handler will emit the dispatcher signal to be
> caught by other window handler??
> 
> By now I'm not using the dispatcher and I'm using a simple
> sigc::signal<void,double> in the system thread, emit it in the
> calculations loop, when the calculations are over(each system is
> launching this signal each 500milliseconds);
> 
> The signal is connected to a handler doing a bind with the threadID,
> so in the handler I have all info I need, and the value is passing to
> the tree view however I see this is not efficient and there is a big
> delay in the update of the "value" column.
> 
> I hope you help with my confusion? And suggest me a better solution.

If you haven't confused yourself then you have certainly confused me.

However, I am not sure if you realise that a sigc::signal object is
just a wrapper for a list of slots (callbacks) - it is akin to a list
of function pointers. The callbacks execute in the thread which emits
the signal. If a worker thread emits the signal then the slots execute
in that thread, which means that those slots must not directly access
any gtkmm methods in the GUI thread.  What you are doing seems to
violate this.

With a Glib::Dispatcher object however, the connected slots execute in
the thread that created the dispatcher, normally the GUI thread,
rather than the thread which emits on the dispatcher.

The normal arrangement is that the GUI thread creates a
Glib::Dispatcher object and connects a slot to it which does whatever
it needs to do when the dispatcher is emitted (following my suggestion,
it would pop a value off an asynchronous queue and put it in your
tree view). It then launches its worker threads.  A worker thread, when
it has anything it wants to pass to the GUI thread's tree view, pushes
it onto the queue and then emits on the dispatcher.

I cannot see how your sigc::signal object comes into it, but so far as
I understand your explanation (which is not very far) you are doing it
wrong.

Chris