Boost logo

Boost Users :

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

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:


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at