Boost logo

Boost :

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at