On Sat, Feb 7, 2015 at 2:12 PM, Klaim - Joël Lamotte <email@example.com> wrote:
> This might be a slightly off-topic question, not sure, but it's related I
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
> 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).
> 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
> 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.
>  https://github.com/chriskohlhoff/executors
> Boost-users mailing list
Boost-users mailing list