Re: Adding custom GDK events

[Chris Vine <chris cvine freeserve co uk>]

On Friday 12 January 2007 15:40, Daniel Elstner wrote:
> Am Freitag, den 12.01.2007, 11:25 +0100 schrieb Murray Cumming:
> > On Fri, 2007-01-12 at 03:03 +0100, Daniel Elstner wrote:
> > > Now wait... are you really sure Glib::signal_idle() is thread-safe?
> >
> > It's meant to be in glib, at least.
>
> Yes, most of GLib is thread-safe if used with some precautions.  The
> problem is that we do not just pass a function pointer to it, but also
> an allocated data structure written to in one thread and read in
> another.  The main problem is that sigc++ uses reference counting
> instead of copy semantics.
>
> BTW that's also the reason I didn't inherit from sigc::trackable in the
> Dispatcher code and thread examples.  I see that you changed that.  It
> might not be an issue at all but it'll need investigating how exactly
> the objects are used in these instances.  Avoiding all the implicit
> behind-the-scenes stuff made sure that it isn't a problem, though.

The glib main loop in glib-2.* is thread safe.  g_idle_add() (and other main 
loop functions) are therefore thread safe in terms of the main loop itself.

As I think you are saying, this does not in itself ensure memory visibility of 
the callback function pointer or data argument of the idle callback (or any 
other data passed between the threads concerned) and if visibility on 
multi-processor systems is required then some form of memory synchronisation 
(fences or barriers) will be required, typically by means of mutex locking of 
the data.

In practice however I suspect this will be achieved since I am pretty sure 
(although this perhaps should be checked and I will do so next week) that 
when g_idle_add() is called the main loop locks and unlocks mutexes for the 
main loop and this will have the effect also of synchronising memory as 
regards the callback.  Therefore, by the time the callback is executed memory 
will have synchronised on any POSIX system.  Furthermore on Unix-like systems 
g_idle_add() uses a pipe and although not guaranteed by POSIX it seems 
inconceivable that in practice writing to a pipe in one thread and reading 
from it in another would not synchronise memory.

If this were not the case g_idle_add() would be ineffective for one of its 
main intended purposes, which is message passing from other threads to the 
main loop thread.

I do not know if glibmm gives rise to further sychronisation issues but I 
would be surprised if it did, in the sense that if there is a problem with 
sigc slots with Glib::signal_idle() then there is a problem with g_idle_add() 
so far as concerns its function pointer and data arguments.

If this is not the case, it may be a good idea for Glib::SignalIdle to 
provides its own internal locking.

Chris