headers
Stjepan Rajko | 13 Oct 21:39
Favicon

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

Hello all,

The review for the Signals2 library (formerly known as
thread_safe_signals - description below) submitted by Frank Mori Hess
has been tentatively scheduled for Nov 1st - Nov 10th.  As per a
recent discussion on the review process (http://tinyurl.com/48tdjs),
and after consulting with the review wizards, we would like to try
something new for this review:  have a number of reviewers commit
beforehand to submitting a review.

The goal of signing up is to ensure that there is both sufficient
interest in the library, and that there will be enough reviews
submitted for an informed decision on acceptance.  If you are
interested in this library, I encourage you to sign up now to be a
reviewer (by this you commit to submitting a review preferably by the
end of the review period).  Of course, additional reviews from
non-signed-up reviewers will also be welcome, but without enough
reviewers signing up beforehand it is not clear that we should proceed
with a review at this time.

To sign up, please send me a reply (here or privately), and let me
know whether the review period is suitable for you (we can make some
adjustments if necessary).  I strongly encourage participation from
reviewers that would examine the library from a purely user standpoint
(commenting on the interface and / or the documentation), as well as
reviewers that would be willing to look into the details of the
implementation (i.e., you don't have to focus on both).  I you would
like to sign up, please let me know by this Saturday (October 18th).

About the library:
(Continue reading)

Permalink | Reply |
headers
Jeff Flinn | 14 Oct 15:11
Favicon

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

Hi Stjepan,

Stjepan Rajko wrote:
...
> * Relationship to Boost.Signals:
> This is a thread-safe variant of the original Boost.Signals library.
> There have been some changes to the interface to support
> thread-safety, mostly with respect to automatic connection management.
> 
> The following thread offers some more details on the differences
> between the two implementations, as well as a plan of a phased
> replacement of Boost.Signals should Signals2 be accepted:
> http://tinyurl.com/4sqau3 [nabble]

It might be more expeditious to directly paste Frank's points from his 
email in the above thread. I've pasted them below. Is the intent to only 
review these changes?

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. Are there examples demonstrating new usage 
patterns? Is there any info on the cost of this thread safe 
implementation vs. the signals1 in a single threaded application?

---
* There is an author change, and the new author (me) has never submitted 
a lib to boost before.  A few of the headers in thread_safe_signals did 
start as copies of boost.signals headers, but it's mostly a new 
implementation.
(Continue reading)

Permalink | Reply |
headers
Frank Mori Hess | 14 Oct 16:04
Favicon

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


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.
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 14 Oct 19:53

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?
(Continue reading)

Permalink | Reply |
headers
Frank Mori Hess | 15 Oct 03:52
Favicon

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

On Tuesday 14 October 2008 13:53, vicente.botet wrote:
> ----- Original Message -----
> From: "Frank Mori Hess" <frank.hess <at> nist.gov>

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

Yes, moving the API changes list up to its own section so it is visible in 
the main TOC seems like a good idea.  A table with removed/deprecated 
features and their replacements does seem like it would be more readable. 

As far as examples showing how to port code goes, there's really not much 
to add at the moment.  Most of the changes are either trivial, so I'd 
giving examples of things like replacing declarations of 
boost::signals::connection with boost::signals2::connection.  Or, they are 
sufficiently different (like the automatic connection management) that 
bringing up the old way while trying to explain the new way doesn't help.  
That is, the appropriate place for both new users of Signals2 and users 
familiar with Boost.Signals to learn about the Signals2 automatic 
connection management is in the tutorial + reference.  I think adding some 
links in the API changes list to the appropriate tutorial section would be 
helpful though.
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 15 Oct 19:58

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

----- Original Message ----- 
From: "Frank Mori Hess" <fmhess <at> speakeasy.net>
To: <boost <at> lists.boost.org>
Sent: Wednesday, October 15, 2008 3:52 AM
Subject: Re: [boost] [thread_safe_signals][signals2] call 
forreviewers(review tentatively scheduled Nov 1st - Nov 10th)
On Tuesday 14 October 2008 13:53, vicente.botet wrote:
> ----- Original Message -----
> From: "Frank Mori Hess" <frank.hess <at> nist.gov>

<snip>

> Yes, moving the API changes list up to its own section so it is visible in
> the main TOC seems like a good idea.  A table with removed/deprecated
> features and their replacements does seem like it would be more readable.

Great

> As far as examples showing how to port code goes, there's really not much
> to add at the moment.  Most of the changes are either trivial, so I'd
> giving examples of things like replacing declarations of
> boost::signals::connection with boost::signals2::connection.  Or, they are
> sufficiently different (like the automatic connection management) that
> bringing up the old way while trying to explain the new way doesn't help.
> That is, the appropriate place for both new users of Signals2 and users
> familiar with Boost.Signals to learn about the Signals2 automatic
> connection management is in the tutorial + reference.  I think adding some
> links in the API changes list to the appropriate tutorial section would be
> helpful though.
(Continue reading)

Permalink | Reply |
headers
Frank Mori Hess | 16 Oct 23:27
Favicon

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


On Wednesday 15 October 2008 13:58 pm, vicente.botet wrote:
> > Now, if it is decided in review that something like a
> > boost::signals2::trackable needs to be added to ease the pain of porting,
> > that is something that would deserve more exposition in the API changes
> > section of the docs.  And discussion/example usage of a
> > signals2::trackable class wouldn't belong in the tutorial, since I'd want
> > to discourage new users from using it.
>
> Do you mean that  signals2::trackable could be included without
> disturbance?

I'm not certain this is what you're asking, but yes it would be possible to 
implement a signals2::trackable on top of the signals2 automatic connection 
management scheme (in fact I did have it implemented at one point).  It 
wouldn't be thread-safe, but it could do everything the boost::trackable from 
Boost.Signals does.

>
> You have misunderstood my concern. I'm talking about a benchmasrk on a
> single threaded application without any mutex. Nothing to be with the
> Thread library.

Oh.  Yes, some benchmarking would be good to post to this list at the 
beginning of the review.  I'll try to do that if we get enough reviewers to 
run with.  Probably it would be good add a benchmark with a signal invoking 
slots with connection tracking enabled (a scenario I imagine Boost.Signals 
would win over Signals2).  Of course, anyone could benchmark and post the 
results.
(Continue reading)

Permalink | Reply |
headers
Stjepan Rajko | 14 Oct 18:51
Favicon

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

Hi Jeff,

On Tue, Oct 14, 2008 at 6:11 AM, Jeff Flinn
<TriumphSprint2000 <at> hotmail.com> wrote:
>
> It might be more expeditious to directly paste Frank's points from his email
> in the above thread. I've pasted them below. Is the intent to only review
> these changes?
>

Thanks for pasting that in.  I think any issue related to the library
would be appropriate to raise during the review, even if it would
apply to the current Boost.Signals library (reviews are good times to
figure things out :-)).  The original Boost.Signals review discussion
can be found here:
http://lists.boost.org/Archives/boost/2002/02/index.php

I'm not sure how applicable that discussion would be now since I
imagine the library has evolved quite a bit over the years, but it
might be useful to revisit if we end up discussing things that apply
to Boost.Signals as well as the proposed library.

> Is there
> any info on the cost of this thread safe implementation vs. the signals1 in
> a single threaded application?
>

I assume that the following comparison was done for a single threaded
app (using dummy_mutex), but if not I suspect the results would be an
upper bound for the single threaded case:
(Continue reading)

Permalink | Reply |
headers
Doug Gregor | 14 Oct 17:33

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

On Mon, Oct 13, 2008 at 3:40 PM, Stjepan Rajko <stipe <at> asu.edu> wrote:
> The review for the Signals2 library (formerly known as
> thread_safe_signals - description below) submitted by Frank Mori Hess
> has been tentatively scheduled for Nov 1st - Nov 10th.  As per a
> recent discussion on the review process (http://tinyurl.com/48tdjs),
> and after consulting with the review wizards, we would like to try
> something new for this review:  have a number of reviewers commit
> beforehand to submitting a review.

I will *definitely* be reviewing this library.

  - Doug
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 14 Oct 18:45

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

----- Original Message ----- 
From: "Doug Gregor" <doug.gregor <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, October 14, 2008 5:33 PM
Subject: Re: [boost] [thread_safe_signals][signals2] call for 
reviewers(review tentatively scheduled Nov 1st - Nov 10th)

>
> On Mon, Oct 13, 2008 at 3:40 PM, Stjepan Rajko <stipe <at> asu.edu> wrote:
>> The review for the Signals2 library (formerly known as
>> thread_safe_signals - description below) submitted by Frank Mori Hess
>> has been tentatively scheduled for Nov 1st - Nov 10th.  As per a
>> recent discussion on the review process (http://tinyurl.com/48tdjs),
>> and after consulting with the review wizards, we would like to try
>> something new for this review:  have a number of reviewers commit
>> beforehand to submitting a review.
>
> I will *definitely* be reviewing this library.
>
>  - Doug

Hi,
The name of Boost.Signal2 seems as the V2 of Boost.Signal. Is it the case?

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Stjepan Rajko | 14 Oct 19:00
Favicon

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

On Tue, Oct 14, 2008 at 9:45 AM, vicente.botet <vicente.botet <at> wanadoo.fr> wrote:
>
> Hi,
> The name of Boost.Signal2 seems as the V2 of Boost.Signal. Is it the case?
>

Hmm... perhaps in a similar way to how Phoenix is planned to be Lambda
V2, yes.  Signals2 is a reimplementation of Boost.Signals to support
thread safety, and if accepted, the plan mentioned by Doug Gregor and
Frank Mori Hess would be to do a phased replacement of Boost.Signals
by Boost.Signals2.  I believe most of the implementation has been
rewritten, but most of the interface kept the same (with additions
related to thread-safety).

Regards,

Stjepan
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 14 Oct 19:45

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

----- Original Message ----- 
From: "Stjepan Rajko" <stipe <at> asu.edu>
To: <boost <at> lists.boost.org>
Sent: Tuesday, October 14, 2008 7:00 PM
Subject: Re: [boost] [thread_safe_signals][signals2] call 
forreviewers(review tentatively scheduled Nov 1st - Nov 10th)

>
> On Tue, Oct 14, 2008 at 9:45 AM, vicente.botet <vicente.botet <at> wanadoo.fr> 
> wrote:
>>
>> Hi,
>> The name of Boost.Signal2 seems as the V2 of Boost.Signal. Is it the 
>> case?
>>
>
> Hmm... perhaps in a similar way to how Phoenix is planned to be Lambda
> V2, yes.  Signals2 is a reimplementation of Boost.Signals to support
> thread safety, and if accepted, the plan mentioned by Doug Gregor and
> Frank Mori Hess would be to do a phased replacement of Boost.Signals
> by Boost.Signals2.  I believe most of the implementation has been
> rewritten, but most of the interface kept the same (with additions
> related to thread-safety).
>
> Regards,
>
> Stjepan

Thanks, now it is clear.
(Continue reading)

Permalink | Reply |
headers
Stjepan Rajko | 14 Oct 19:28
Favicon

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

On Tue, Oct 14, 2008 at 8:33 AM, Doug Gregor <doug.gregor <at> gmail.com> wrote:
> On Mon, Oct 13, 2008 at 3:40 PM, Stjepan Rajko <stipe <at> asu.edu> wrote:
>> The review for the Signals2 library (formerly known as
>> thread_safe_signals - description below) submitted by Frank Mori Hess
>> has been tentatively scheduled for Nov 1st - Nov 10th.  As per a
>> recent discussion on the review process (http://tinyurl.com/48tdjs),
>> and after consulting with the review wizards, we would like to try
>> something new for this review:  have a number of reviewers commit
>> beforehand to submitting a review.
>
> I will *definitely* be reviewing this library.
>

Thank you - you saved me the trouble of pestering you otherwise :-)

Stjepan
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Olaf Peter | 14 Oct 18:53

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

> The review for the Signals2 library (formerly known as
> thread_safe_signals - description below) submitted by Frank Mori Hess
> has been tentatively scheduled for Nov 1st - Nov 10th.  As per a

what is the difference to/advantage over Dataflow.Signals
(http://dancinghacker.com/code/dataflow/dataflow/signals.html)?

Regards,
Olaf
Permalink | Reply |
headers
Stjepan Rajko | 14 Oct 19:04
Favicon

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

On Tue, Oct 14, 2008 at 9:53 AM, Olaf Peter <ope-devel <at> gmx.de> wrote:
>> The review for the Signals2 library (formerly known as
>> thread_safe_signals - description below) submitted by Frank Mori Hess
>> has been tentatively scheduled for Nov 1st - Nov 10th.  As per a
>
> what is the difference to/advantage over Dataflow.Signals
> (http://dancinghacker.com/code/dataflow/dataflow/signals.html)?
>

Dataflow.Signals is a layer of the Dataflow library which uses
Boost.Signals.  As the Signals2 / thread_safe_signals library is
mostly interchangeable with Boost.Signals, Dataflow.Signals can also
use thread_safe_signals instead of Boost.Signals.  However, there is
really no overlap in the functionality offered by Dataflow.Signals and
Signals2 (the former just uses the latter).

Regards,

Stjepan
Permalink | Reply |

Gmane