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