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

Subject: Re: [boost] [signals2] extended_slot_type bug with preferred syntax
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-13 18:48:44

----- Original Message ----- 
From: "Frank Mori Hess" <frank.hess_at_[hidden]>
To: <boost_at_[hidden]>
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_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.

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