[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 14.06.2004 01:20:26 schrieb(en) Daniel Elstner:
> Am So, den 13.06.2004 um 22:18 Uhr +0200 schrieb Martin Schulze:
> 
> > time    thread A should do (*does)               thread B [*does]
> > -------------------------------------------------------------------
> > t       construct slot
> >                     (*slot is partly constructed)
> > t+2     acquire lock
> >                     (*lock is acquired)
> > t+3     add slot to list
> > t+3     release lock
> >                     (*slot is added to list)
> >                     (*lock is released)
> > t+4     idle                                      [*accesses slot]
> > t+5                 (*construction of slot is finished)
> >
> >
> > Is this a possible scenario? I can't think properly about it at the
> 
> > moment - too tired. Note that slot is copied again while adding to
> the
> > list during std::list::push_back(). I would assume that this copy  
> is
> 
> > fully initialized before the lock is actually released. Of course  
> in
> 
> > the case of our std::string this is still a problem because the
> newly
> > constructed string is a shallow copy of the old one. But for static
> 
> > data types everything should be all right, shouldn't it?
> 
> Yes.  But at least in libsigc++ 1.2, slots were reference-counted.
> Has
> this changed in 2.0?

Yes, this has changed. Reference-counting of slots made signal emission  
very complex and had very little benefits. Apart from the template  
clutter which make it hard to read, the internals of libsigc++ 2.0 are  
much more simple than in libsigc++ 1.2!

Cheers,

  Martin