-----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. an explanation of why signals2::mutex exists -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJHKqQ5vihyNWuA4URAinHAJ9kWdts86XbKuXQM51TDaey2J7erwCgrMNc LgdjS55kdGWfpJyz1CU/TkM= =69o0 -----END PGP SIGNATURE-----