----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov> To: <boost@lists.boost.org> Sent: Thursday, November 13, 2008 11:30 PM Subject: Re: [boost] [signals2] extended_slot_type bug with preferred syntax
-----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@nist.gov>
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.
Independently of if the library is accepted or accepted conditionally, I would like to participate in a mini-review with all the material you plan to add and improbe. Good Luck, Vicente