Re: Event loop hangup when using TimeoutSource and IdleSource

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 24 Sep 2009 15:03:08 -0400
Jim Hodapp <james hodapp gmail com> wrote:
> Robert,
> 
> I just did an initial step through of the code attaching to the  
> program via gdb -p <pid> after it hung and the bt shows that it is  
> getting stuck after doing one of the set_text calls for a label. So
> it seems to possibly be a race condition still. 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. I've already proven this library out with a ncurses GUI
> that I wrote since it was pretty quick and easy and I'd done several
> ncurses GUIs in the past. Not to say that there aren't bugs still,
> but the general flow of the library is pretty sound.
> 
> 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.

[snip]

It may well not be related to your specific problem and I am not
clear what in your code is doing what in what thread, but nonetheless
you cannot call Glib::signal_idle().connect() from a worker thread as
it is not thread safe.  If you want to post idle handlers from other
than the GUI thread, then you will have to use g_idle_add_full()
directly, which is thread safe, but you may be better off with
Glib::Notifier.

I assume also that you have called Glib::thread_init()?

Chris