Re: Event loop hangup when using TimeoutSource and IdleSource

[Jim Hodapp <james hodapp gmail com>]

Chris,

    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.

Thanks,

Jim


On Sep 24, 2009, at 5:21 PM, Chris Vine wrote:

> On Thu, 24 Sep 2009 17:02:00 -0400
> Jim Hodapp <james hodapp gmail com> wrote:
> >     I am sure that the library does not touch GTK+ functions. It's
> > a C library and the only thing that touches the GUI is the GUI app
> > itself and that's only via C++ and gtkmm. The library does no output
> > other than to stderr. The library calls only get called one at a
> > time. The only thing that is *parallel* is the loop in the library
> > that is in a separate thread that calls select() to see if there's
> > anything on the serial port to read, and checks the message queues to
> > see if any commands need to go out to the device. I have the function
> > that adds a new command to the message queue protected with a mutex
> > just in case I ever have a GUI frontend that is multithreaded.
>
> Jim,
>
> I cannot quite reconcile your "adding things to the message queue" on
> the one hand (dangerous) particularly with your reference to doing
> so under an (unnecessary) lock, with "the library does no output other
> than to stderr" on the other (safe), but you obviously know what you
> are doing.
>
> I am out of suggestions I am afraid.
>
> Chris