Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Ben Pope (benpope81_at_[hidden])
Date: 2015-02-08 01:21:08

On Sunday, February 08, 2015 04:12 AM, Klaim - Joël Lamotte wrote:
>
> ​This might be a slightly off-topic question, not sure, but it's related
> I think:
> Does it seam useful to people using signals2 or similar library to
> consider another kind of signal type
> which would take an Executor [1] concept instance on construction,
> system's executor (thread-pool)
> by default, and would then use that executor for dispatching calls? (one
> task pushed by listener).

I think it would be nice to have an executor on the slot, too.

> That is, when a signal is called, it pushes as many tasks in the
> executor as there is listeners and returns.
> It makes the dispatching either "in order" if the executor is a strand
> or not if it's not.
> This signal type would not make any guarantee about the which thread
> would call the listening objects.

An executor in the slot lets the subscriber decide which thread calls 
into its code.

If the slots are primarily synchronous, you might prefer an asynchronous 
signal, if they are primarily asynchronous, a synchronous signal may 
suffice.

This presents you with a fun game for return values.

I think the default for both should be synchronous though, otherwise the 
benchmarks look worse :P

This then starts to look a lot more like observe_on and subscribe_on 
from rxcpp:
https://github.com/Reactive-Extensions/RxCpp/
http://www.introtorx.com/Content/v1.0.10621.0/15_SchedulingAndThreading.html

Ben