Re: Glib::SignalIO Help

[Chris Vine <chris cvine freeserve co uk>]

On Fri, 12 Nov 2010 11:58:36 -0600
Michael Sierks <msierks sierkstech net> wrote:
> On 11/12/2010 04:08 AM, Chris Vine wrote:
> > On Thu, 11 Nov 2010 22:49:05 -0600
> > Michael Sierks<msierks sierkstech net>  wrote:
> >> Hello,
> >>
> >> I am writing a network application and currently have a separate
> >> thread for handling connections. But I am having an issue with
> >> calling "Glib::signal_io().connect()" to monitor a file descriptor
> >> in the thread. Whenever I do the gui freezes for some reason. This
> >> is a little puzzling, would anyone know why ?
> > You had better explain a bit more what you are trying to do,
> > possibly with a test case. Glib::signal_io().connect() connects the
> > source to the main (GUI) program loop, not any arbitrary main loop
> > any particular worker thread may be running.
> >
> > You can connect to a particular thread's main loop if you do it the
> > long way of course, using Glib::IOSource::attach().
> >
> > Note that because sigc::trackable is not thread safe, and some of
> > the main loop code in glibmm is also not thread safe, all these
> > calls should be made in the thread in which the callback is to
> > execute (which also means that Glib::signal_io().connect() should
> > only be called in the main GUI thread).  If you want greater thread
> > safety than that, then you will need to use glib directly, or use a
> > different wrapper library.  Also don't forget to call
> > g_thread_init()/Glib::thread_init().
> >
> > Chris
> >
> >
> You answered my question, attach was causing the problem. I am
> calling...
> 
>              const Glib::RefPtr<Glib::IOSource> io_source = 
> Glib::IOSource::create(sockfd, Glib::IO_IN);
>              io_source->connect(sigc::mem_fun(*this, 
> &TestClass::recvMessage));
>              io_source->attach();

That really shouldn't make any difference from a call to
Glib::signal_io().connect(), because your call to attach() will
(according to the documentation) attach to the default context - the
same as Glib::signal_io().connect() - which is the main GUI context, and
that is not thread safe in glibmm if done from a worker thread.  It may
appear to work, but it will not do so reliably.

If the callback executes in the main GUI context you should use glib's
GIOChannel directly, or consider using the asynchronous io functions
in giomm, or use a thread-safe wrapper, such as
http://cxx-gtk-utils.sourceforge.net/group__io__watch.html .

If however the worker thread has its own main loop, then you can use
the version of Glib::IOSource::attach which takes the thread's own main
context as an argument.

What threads in your program are doing what?

Chris