Re: Event loop hangup when using TimeoutSource and IdleSource

[Jim Hodapp <james hodapp gmail com>]

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.

Thanks,

Jim Hodapp

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

> 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