-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 23 February 2007 17:16 pm, Peter Dimov wrote:
My initial iteration of this hypothetical design would also incur several shared_ptr/intrusive_ptr copies on operator() to address the thread safety issues in the most obvious "snapshot" way, that is, the signal invokes the slots that were connected at the time operator() was called. Subsequent concurrent modifications to the slot container do not affect the invocation in progress. This has the advantage of being highly scalable and deadlock-resistant.
Such an approach may turn out to not be acceptable, though, given that the majority of signal benchmarks place heavy emphasis on operator() calls.
Actually, since we started dropping all locks before running a slot, it has occurred to me that per-slot locking no longer buys us much concurrency-wise. Getting rid of the slot locks would require creating a list of unblocked slots at the beginning of signal invocation while holding the (only) mutex, before running any slots. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF33Rb5vihyNWuA4URAghdAKCxz1ja1Pbst1SaWGa5Ao8LRr1ANwCgtavD FncsSdKcdrBExnsangaoCww= =enpX -----END PGP SIGNATURE-----