Boost Users :
Subject: Re: [Boost-users] Signals2 benchmark
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-02-08 13:13:36
On Sun, Feb 8, 2015 at 11:49 AM, Klaim - JoÃ«l Lamotte <mjklaim_at_[hidden]> wrote:
> On Sun, Feb 8, 2015 at 4:42 PM, Michael Powell <mwpowellhtx_at_[hidden]>
>> On Sun, Feb 8, 2015 at 8:02 AM, Klaim - JoÃ«l Lamotte <mjklaim_at_[hidden]>
>> > 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,
> 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 list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net