----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov> To: <boost@lists.boost.org> Sent: Tuesday, October 14, 2008 4:04 PM Subject: Re: [boost] [thread_safe_signals][signals2] call for reviewers(review tentatively scheduled Nov 1st - Nov 10th)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 14 October 2008 09:11 am, Jeff Flinn wrote:
It might help if there were a summary section on the diffs with this new version. Glancing over the documentation it wasn't clear where to find the differences other than the section mentioned above for Automatic Connection Management.
There is an entry in the FAQ section which has a summarized list of changes.
This is a good starting point, but in my opinion it should appear in the introduction or on a history section. It would be interesting to sum up in a table which classes/functions are compatible, which are not supported/depreceated and which are new, which new features can be adopted to Boost.Signal? I expect also some examples that show how the non supported/depreceated Boost.Signal are replaced by the equivalent Boost.Signal2. You don't think this must be done before the review?
Are there examples demonstrating new usage patterns?
The tutorial section of the docs has been updated to the new API. There is no example code for the signal::extended_slot_type and signal::connect_extended() stuff I squeezed in at the last minute, but they are in the reference section.
Do you plan to add some tutorial/examples of these new features before the review?
Is there any info on the cost of this thread safe implementation vs. the signals1 in a single threaded application?
The only benchmarking/optimization I've done is to compare the invocation speed of a signal with zero slots connected. IIRC signals2 was slightly faster. It is probably still possible to optimize the automatic connection tracking overhead during invocation, maybe using a custom allocator for the vector of tracked shared_ptr. I don't know anything about the relative memory usage of the two libs.
Where can we find this benchmarking, on the documentation?
As far as single-threaded apps go, the signal class does have a Mutex template type parameter, and the library provides signals2::dummy_mutex which can be used to eliminate locking overhead.
I think that a benchmark/comparation of the Boost.Signal2 with a signals2::dummy_mutex parameter and the Boost.Signal is mandatory. Otherwise we let each user check which one is better on a single_thread environement. BTW, this dummy mutex should be a good candidate to the thread library. There is already one null_mutex class in the interprocess library. Best, Vicente