Re: glibmm thread safety

[Daniel Elstner <daniel kitta googlemail com>]

Am Montag, den 15.01.2007, 18:35 +0000 schrieb Chris Vine:

> 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,

Well, the API simplification would be useful for SignalTimeout, too.  As
to the others, I agree.

> 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).

The generic Glib::Source in glibmm stuff is completely separate from the
convenience API Glib::signal_idle() and friends.  That of course needs
to be investigated as well.

If the new API is added, I think the docs should suggest to always use
connect_once() where appropriate since it is simpler.  Whether it is
necessary to mention threading depends on whether we can fix the plain
connect().

--Daniel