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  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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net