Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-02-08 10:42:29

On Sun, Feb 8, 2015 at 8:02 AM, Klaim - Joël Lamotte <mjklaim_at_[hidden]> wrote:
>
>
> On Sat, Feb 7, 2015 at 9:46 PM, Michael Powell <mwpowellhtx_at_[hidden]>
> wrote:
>>
>> On Sat, Feb 7, 2015 at 2:12 PM, Klaim - Joël Lamotte <mjklaim_at_[hidden]>
>> wrote:
>> >
>> > This might be a slightly off-topic question, not sure, but it's related
>> > I
>> > think:
>>
>> I could be wrong, but isn't an executor exactly what a signal is
>> already, i.e. when you specify signal-of-function, and connect
>> to/disconnect from it? The signal/event source makes the callback,
>> which I assume are stored in a FIFO order.
>>
>> I can't speak to callback ordering, per se. It seems like FIFO would
>> be a natural assumption. It would be equally interesting to specify
>> that strategy, allowing for LIFO, for example, or even prioritized
>> callbacks.
>>
>
>
> An executor takes arbitrary tasks as input and only
> guarantee that these tasks will be executed, under some constraints
> defined by the specific executor type.
> A signal dispatch it's call and parametters to a set of observers.

Using the Boost.Signals2 for example, it is easy AFAIK to type-define
a signal, and re-use that type anywhere that signal is required. So a
listener could receive a signal, and subsequently do whatever it
wanted to with that message; dispatch it again, process it,
whatever...

> Basically, when the signal calls the observers, it's trigerring the
> execution of work/tasks.
> I am then suggesting to dissociate the work done by the signal, that is
> trigerring the
> dispatching, and the actual way the observers would be called, which would
> depend on the
> the executor kind.
>
>  If you will, it's like the current signals2 had a hard-coded executor
> inside, and
> that some would want to pay for the flexibility of being able to specify the
> executor
> on construction.

I haven't looked at the signals2 code recently, except from recent
experience using Boost.Signals2. It would be interesting to inject a
Dispatcher handler. Default might be a synchronous call; one option
might be to provide an async/futures based dispatcher, for example.

>>
>> > 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).
>> > 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.
>>
>> I've considered that parallelism, concurrency, threading, reentrancy
>> to be the job of the callee. At the source of the signal/event, these
>> concerns are assumed, and the callee must handle such potential
>> collisions.
>>
>
> I agree. I think it would potentially affect more the scalability of the
> calls, not
> the callees (which still have to be protected against concurrent calls as
> you point).
> That is, if a signal with a lot of observers is called very often, it would
> dispatch a lot of
> obverver call tasks which, if pushed in a thread_pool, would be called ASAP
> without
> blocking/locking the signals call function (much).

See abive; my two cents, re: potentially injecting an asynchronous dispatcher.

>> > It seems to me that in some cases I have encountered (highly concurrent
>> > task-based systems with a lot of message dispatching
>> > between "actors"-like objects),
>> > this kind of model might be more interesting
>> > performance-scalability-wise
>> > than the current mutex-based dispatching of signals2.
>> > I didn't try to compare and measure performance though and I might be
>> > totally wrong.
>>
>> I haven't measured for performance myself, but it at least 'works' in
>> a multi-threaded situation, i.e. where I may be passing messages to a
>> pub/sub endpoint, which is subsequently packaged for deliver to
>> subscribers. This works pretty well, guarding the boundaries with
>> appropriate mutex-based or other locking.
>>
>> > [1] https://github.com/chriskohlhoff/executors
>> >
>> >
>> > _______________________________________________
>> > Boost-users mailing list
>> > Boost-users_at_[hidden]
>> > http://lists.boost.org/mailman/listinfo.cgi/boost-users
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users