Re: glibmm thread safety [was: Re: Adding custom GDK events]

[Chris Vine <chris cvine freeserve co uk>]

On Monday 15 January 2007 17:27, Murray Cumming wrote:
> On Mon, 2007-01-15 at 18:03 +0100, Daniel Elstner wrote:
[snip]
> > I like that idea.  It's useful beyond solving the threading problems as
> > well, as you no longer need to use sigc::bind_return(), or change the
> > code to return a boolean.  I'd prefer to call it connect_oneshot() or
> > connect_once(), though.  Murray?
>
> Sounds generally fine, as long as there's clear documentation saying
> when you should use it, and when not to use the other one.

To complete the thought, it doesn't seem worth providing something similar for 
Glib::SignalIO::connect(), Glib::SignalTimeout::connect() or 
Glib::SignalChildWatch::connect() because they do not have the specialist 
usage that Glib::SignalIdle does, other than to document that they must be 
called in the main loop thread (and perhaps suggesting that either users 
should use the glib API in the unlikely event of them wanting to connect up 
watches/timeouts in some other thread, or should hand on the connection of 
such other Glib::Source objects to Glib::SignalIdle::connect_once() - I am 
pretty certain it is safe to create and attach new GSource objects in main 
loop callbacks but this would also need to be checked before making the 
suggestion given the locking going on).

Chris