Subject: Re: [boost] [thread_safe_signals][signals2] call for reviewers(review tentatively scheduled Nov 1st - Nov 10th)
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-10-14 13:53:42
----- Original Message -----
From: "Frank Mori Hess" <frank.hess_at_[hidden]>
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
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
> 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
> are in the reference section.
Do you plan to add some tutorial/examples of these new features before the
>> 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
> tracking overhead during invocation, maybe using a custom allocator for
> 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
> type parameter, and the library provides signals2::dummy_mutex which can
> 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
BTW, this dummy mutex should be a good candidate to the thread library.
There is already one null_mutex class in the interprocess library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk