Re: [Boost-users] Boost-users Digest, Vol 4049, Issue 1

Thanks Howard ! On Monday, February 9, 2015 12:00 PM, "boost-users-request@lists.boost.org" wrote: Send Boost-users mailing list submissions to     boost-users@lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit     http://lists.boost.org/mailman/listinfo.cgi/boost-users or, via email, send a message with subject or body 'help' to     boost-users-request@lists.boost.org You can reach the person managing the list at     boost-users-owner@lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost-users digest..." Today's Topics:   1. Re: Signals2 benchmark (Klaim - Jo?l Lamotte)   2. Re: Signals2 benchmark (Michael Powell)   3. write starvation of upgradable lock (David Frank)   4. Re: write starvation of upgradable lock (Howard Hinnant)   5. Re: Signals2 benchmark (Nevin Liber)   6. Re: [Serialization] XML: float format is scientific instead       of human-readable since Boost 1.57 (Frank St?hr)   7. Re: Signals2 benchmark (Dominique Devienne) ---------------------------------------------------------------------- Message: 1 Date: Sun, 8 Feb 2015 18:49:06 +0100 From: Klaim - Jo?l Lamotte To: Boost users list Subject: Re: [Boost-users] Signals2 benchmark Message-ID:     Content-Type: text/plain; charset="utf-8" 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.