Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-02-07 15:46:11

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.

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

> 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