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