On Sat, Feb 7, 2015 at 9:46 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:

On Sat, Feb 7, 2015 at 2:12 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> 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@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users