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