Re: [boost] [signals2] extended_slot_type bug with preferred syntax

Subject: Re: [boost] [signals2] extended_slot_type bug with preferred syntax
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-11-13 17:30:40

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 12 November 2008 05:32 am, vicente.botet wrote:
> ----- Original Message -----
> From: "Frank Mori Hess" <frank.hess_at_[hidden]>

> >
> > Hmm, yes I think adding a section on thread-safety to the design overview
> > would help a lot.
>
> Could you scketch how do you plan to do this section if the libarry is
> accepted before the review manager gives the result of the review?
>

The design overview would:

specify which classes/methods are protected by internal mutexes

explain why the shared_ptr/weak_ptr connection management is relevant to 
thread-safety, and similarly for signal::connect_extended()

explain why the postconstructor stuff exists (no shared_from_this() for 
tracking in constructors).

go over some possible choices for the Mutex template type parameter of a 
signal

step through signal invocation, describing when it locks/unlocks internal 
mutexes, what connection list it uses, and when it sees concurrent 
disconnections/connections.

The rationale section would get: 

some notes on changes like last_value/optional_last_value and 
boost::trackable.

an explanation of why signals2::mutex exists
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJHKqQ5vihyNWuA4URAinHAJ9kWdts86XbKuXQM51TDaey2J7erwCgrMNc
LgdjS55kdGWfpJyz1CU/TkM=
=69o0
-----END PGP SIGNATURE-----