Threading signal (was New 'GObject')

[Karl Nelson <kenelson ece ucdavis edu>]

[...]
> > My argument for why it would be better to make the signal emission 
> > capable of being being completely thread afe has always been
> > shot down as not necessary because you need to have global locks
> > for gtk+ any way.  If this part comes off of gtk+ then it
> > will be more of a reason to either remove those parts needing 
> > locks or add locks to those parts.  :-)  If we are talking about a
> > general object system to be used in things like sound systems
> > emits of signals must become something better than a global lock.
> > (At least from what I would guess.)
> 
> Well, yes. 
> 
> There are two separate issues here:
> 
>  - The ability to emit signals on two different objects from
>    two different threads. 
> 
>    This is definitely worthwhile if we split out the GTK+ object
>    system and comes almost free if you make the emission lists
>    per-thread. (The only remaining difficulty is some free
>    lists that would need to be locked or replaced.)

I managed to implement all of libsigc++ without the emission lists,
but then I am missing the feature of canceling an emission in
progress.  On the flip side I could cancel the thread through the
marshaller, so it wasn't as necessary.  If emission cancellation
through something other than the marshaller is required then
we just need to lock the lists to be per thread.

 
>  - Some sort of automatic locking so it is safe to emit signals from
>    two different threads on the same object.
> 
>    Not easy to do, and not that useful.

I have looked over this problem extensively in libsigc++.  
I agree completely.  Objects shared between threads must
be locked by the user.  

There is one complexity that unfortunately I don't have a solution
for.  That is that signals connect objects and thus you may
not know that you are using an object from another thread.  
So far it has been safe to ignore that in libsigc++, but I don't
know if that is a good policy.

--Karl