Re: [Boost-users] Signals2 benchmark

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]>
> wrote:
>>
>> On Sun, Feb 8, 2015 at 8:02 AM, Klaim - Joël Lamotte <mjklaim_at_[hidden]>
>> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users