Re: Event loop hangup when using TimeoutSource and IdleSource

[Jim Hodapp <james hodapp gmail com>]

Chris,

    My description of how the GUI thread interacts with the library  
thread wasn't quite accurate. The GUI thread does make direct API  
calls and these API calls are in the same thread space as the GUI  
thread. These commands are added to a message queue which is serviced  
by the separate thread in the device library. This thread checks for  
messages to send to the device, sends the highest priority one, then  
iterates, not sending any new messages to the device until the  
previous one returns. Once it returns, the reply is parsed and the  
returned value is placed into the proper data type. The stored pointer  
to the callback from the GUI frontend part is then called with the  
returned data as a callback parameter.

Jim


On Sep 24, 2009, at 4:36 PM, Chris Vine wrote:

> On Thu, 24 Sep 2009 16:27:11 -0400
> Jim Hodapp <james hodapp gmail com> wrote:
> > Chris,
> >
> >     I am not setting up the Glib::signal_idle().connect() in a
> > separate thread from the main GUI thread. Only the library which
> > communicates with the device is in a separate thread. That library
> > is all C and doesn't touch gtkmm or glibmm at all. The backtrace made
> > me want to double check the scope on my instance of "this" that I'm
> > passing to the library, then the library passes to the callback
> > wrapper function in which the signal_idle connection uses to call
> > the final callback function that modifies the GUI widget(s). I
> > imagine if "this" went out of scope somehow that sigc and glibmm
> > wouldn't like that much when destroying the idle handler reference.
>
> Jim,
>
> If you are passing arguments to an idle handler it is best to have
> them on freestore and free them in the handler if they are not passed
> by value, as of course they need to be around until the point at which
> the main loop gets around to executing the slot. There is a separate
> issue of the target object method invoked by the handler remaining in
> existence, but you can get automatic slot disconnection with
> sigc::trackable.  You are probably well aware of this and it may well
> not be related to your problem.
>
> Just out of interest (as I am interested in such things), how does the
> device library thread communicate with the GUI thread?
>
> Chris