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

Subject: Re: [boost] [thread_safe_signals][signals2] call for reviewers (review tentatively scheduled Nov 1st - Nov 10th)
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-10-14 10:04:51

-----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.

> 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.

> 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.

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI9KcE5vihyNWuA4URAu34AKCnCOF4isPA25bEhJ3blPHOoeUsQQCeIvkN
IkQ+bdpEt9m4RWZPGJoh/VM=
=U/k4
-----END PGP SIGNATURE-----