Re: [boost] Synapse library review starts today December 2

Subject: Re: [boost] Synapse library review starts today December 2
From: Nat Goodspeed (nat_at_[hidden])
Date: 2016-12-05 12:31:12

On Sun, Dec 4, 2016 at 10:25 PM, Gavin Lambert <gavinl_at_[hidden]> wrote:

> Instance-based signals like you're talking about are what Signals2 does.  It has the benefit of callbacks being stored locally, at the cost of being intrusive (the object raising the signal needs to contain the signal instance).
>
> This library takes the other approach of being non-intrusive and storing the signal implementations elsewhere -- the benefit is that you can have objects emit signals on behalf of other objects that don't need to know that the signalling framework exists, but comes with some performance costs as a result.
>
> Some use cases would naturally lend itself to one, while others would lend itself to the other.  If all of the code is controlled by you then using Signals2 probably makes more sense, since it's trivial to include the signals in your own classes and it gives you better performance (in theory -- YMMV with mutexes).
>
> But Klemens is asserting that there are some cases where the alternate design is more useful; while I can't think of any such cases I've personally encountered, I have little doubt that they could exist and as such a library that supports it could be useful.

I think what confused me about the Synapse documentation was the use
of the term "emitter," which suggests a locally-stored signal
instance. The reason I asked earlier about a thread-local map keyed by
void* was that understanding that (possible) implementation cleared up
the conceptual model for me.

In one of our applications, we use an "event" framework in which
senders and receivers are loosely coupled. Any given sender and
receiver can communicate, regardless of the relative order in which
they are constructed, by consulting a central map with find-or-create
semantics. They need only agree on the map key. In other words, I
believe that application has use cases of the kind that Synapse
intends to address.

(But the connection need only be made once for each receiver -- the
search isn't performed all over again on every event. I expect the
same is true for proper use of Synapse.)

So for me the term "rendezvous point" makes more sense than "emitter."

To me the Synapse library looks like this:

* front-end API based on a central map of rendezvous points
* back-end implementation of rendezvous points that essentially
duplicates Boost.Signals2, with some features omitted (as in the
critiques earlier in this thread)

Our map's mapped_type is (a thin class wrapped around)
boost::signals2::signal. So while I understand the value of having a
central map of rendezvous points, I do not understand why you would
use anything other than Boost.Signals2 on the back end.

It may be that I missed a really good reason in the discussion above.
But if it's there, I did miss it. Until I understand that really good
reason, I'm not keen on introducing a whole new back-end signals
implementation into Boost.