On Thu, 24 Sep 2009 15:03:08 -0400 Jim Hodapp <[email protected]> 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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
