Re: [thread_safe_signals][signals2] call for reviewers(review tentatively scheduled Nov 1st - Nov 10th)

----- Original Message ----- 
From: "Frank Mori Hess" <frank.hess <at> nist.gov>
To: <boost <at> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost