Re: [Boost-users] Signals2 benchmark

On Sun, Feb 8, 2015 at 11:49 AM, Klaim - Joël Lamotte wrote:

On Sun, Feb 8, 2015 at 4:42 PM, Michael Powell wrote:

...

On Sun, Feb 8, 2015 at 8:02 AM, Klaim - Joël Lamotte wrote:

...

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.

Using the Boost.Signals2 for example, it is easy AFAIK to type-define a signal, and re-use that type anywhere that signal is required. So a listener could receive a signal, and subsequently do whatever it wanted to with that message; dispatch it again, process it, whatever...

Yes but the executor would specify how the observers are notified, not how the observer's work is executed (which depends on the observer implementation indeed). There is an important nuance here.

Yes, I understand. See prior note concerning Dispatcher interfaces. Not sure that there is such an animal in the current Boost.Signals2 version, per se. A default Dispatcher might be synchronous, whereas an asynchronous Dispatcher could be provided. I am at best intermediate knowledge where async, futures, promises are concerned, or if something like that is even possible with Signals2.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users