Re: Event loop hangup when using TimeoutSource and IdleSource

[Robert Pearce <rob bdt-home demon co uk>]

Hi Jim,

On Thu, 24 Sep 2009 15:03:08 -0400 you wrote:
> Robert,
> 
> The library that I wrote  
> that talks to the device runs in its own thread separate from the  
> gtkmm app thread. It talks to the device via file descriptors to the  
> serial port and uses select() to get the data back. It then  
> reassembles the data according to the protocol embedded datatype and  
> passes it as a void * to the callback wrapper function like the one I  
> posted. 

Ah, that has me worried already. As I recall, your callback function includes 
    Glib::signal_idle().connect(sigc::bind(sigc::mem_fun(*emsac,  
       &Emsac::getPrimaryPackCurrentCb), current), Glib::PRIORITY_HIGH_IDLE);

That's not guaranteed thread-safe, if I remember rightly.

> 
> The only functions that ever change properties of the GUI widgets are  
> always called via a callback from the IdleSource instance. Since the  
> event loop should be idle, I don't understand why things would  
> randomly hang up.

Well, there are a number of possible causes when threads are involved :(

> 
> One run ended on the getPrimaryPackCurrentCb function. The following  
> is the backtrace from gdb:
> 
> INFO: (14:58:50) Entering setControlSetpointCb
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb6cc5720 (LWP 20547)]

Interesting - that's not just a hang, you've got a SIGSEGV in one of your threads.

> 0xb762f742 in sigc::internal::trackable_callback_list::remove_callback  
> () from /usr/lib/libsigc-2.0.so.0
> (gdb) bt

And that's the aspect of libsigc++ that was recently noted as being not thread-safe.

Try re-working your data hand-over to use only global data storage and Glib::Dispatcher

Also, dig out Chris Vine's recent posting about this in the "Thread problem in Windows" topic, since he knows a LOT more about GTKmm and threading than I do.

Cheers,
Rob