Re: Event loop hangup when using TimeoutSource and IdleSource

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 24 Sep 2009 17:33:55 -0400
Jim Hodapp <james hodapp gmail com> wrote:
>      You are correct that the lock is unnecessary right now.  
> Originally, I tried making a new thread in the GUI app to handle  
> making calls to the library and so it was possible for multiple  
> commands to be added to the message queue in the library *at the
> same time*. I have since removed this thread and like I originally
> posted, am using a TimeoutSource off of the main Glib event loop to
> run my function that requests status updates from the device library
> every 100 ms. I just decided to keep the lock in there since it's
> currently not hurting anything (to my knowledge). I will take up your
> advice and try replacing the sigc slots and connections with the
> boost signals2 version and see if that changes things at all.
> 
> Maybe you can give me a quick rundown on how sigc uses the instance
> of an object that you pass to it and how that instance going out of
> scope might affect things. For example:
> 
> Glib::signal_idle().connect(sigc::mem_fun(*emsac,  
> &Emsac::setPWMStateCb), Glib::PRIORITY_HIGH_IDLE);
> 
> Does sigc simply use emsac to call setPWMStateCb for the specific  
> instance of emsac? I find sigc's documentation lacking and so an  
> explanation (if you are well versed with it) would be greatly  
> appreciated.

Jim,

Our e-mails have crossed again.

Don't bother trying out boost::signal2 as I am pretty certain that this
is not a threading issue in view of what you have said.  (And exactly
the same points as I mention below would apply if you did use it.)

There are two points on slots executed via a main loop.  First the
arguments bound to it must last until the slot has executed in the main
loop. Since you don't appear to have bound arguments that is not an
issue. Secondly, if the slot represents a non-static method of an
object, that object must also be in a valid state when the slot
executes (which you can assure with sigc::trackable), together with any
other objects addressed in the method.

So one question, again relating to this second point, is whether the
object pointed to by emsac is still valid when the slot is executed by
the main loop.

But that doesn't seem to be the issue in this case since your backtrace
showed you have a NULL Gtk::Label pointer lying around.  I think you
need to look into why that is the case.

Chris