Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2015-02-08 09:02:53

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.

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.

> > 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).

> > 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
>