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

Subject: Re: [boost] Synapse library review starts today December 2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-12-05 20:59:19

On Sun, Dec 4, 2016 at 4:52 PM, Klemens Morgenstern <
klemens.morgenstern_at_[hidden]> wrote:

> I suppose if it is elaborate enough you'd rediscover Synapse, but with a
> different low level machinery, though I suspect that both libraries contain
> incompatible intricacies which make sense in the different approaches they
> take, since non-intrusiveness (in the way Synapse is non-intrusive) was not
> a design goal of Signals2.
> That may be true; there are lots of problems, which look somewhat easy
> from the outside but if you try to actually implement a solution you
> discover a horrible mess of details. I'm just wondering that, and I think
> you're in a situation where it would be very beneficial to explain this
> more, since boost.signals2 exists.
>

I added a new documentation page discussing the similarities and
differences between Signals2 and Synapse:
http://zajo.github.io/boost-synapse/Comparison_between_Boost_Signals2_and_Synapse.html
(here I would like to apologize if I got something about Signals2 wrong,
please someone do correct me if I did.)

To answer your concerns:

First, in Signals2 signals are objects while in Synapse they are types. The
notion of emitter does not exist in Signals2, the signal object does the
emitting, but the emitter (in the traditional sense) would be the object
the signal object is a member of. This makes sense in Signals2 because it
has no use of emitters as such, but in Synapse the concept of the emitter
object is central. Both designs make sense independently, but there is a
clash of terms that would be next impossible to communicate to the average
user.

Second, while it may be possible to use Signals2 signal objects simply as a
storage for connected functions to call (in a supposed attempt to use
Signals2 as a sort of back-end for Synapse, or to "Synapsify" Signals2),
that in itself would be little more than a list of functions. Since Synapse
organizes all connections of a given type into a single data structure,
it's probably possible to turn this into a list Signals2 signal objects per
Synapse signal type, but I don't see the benefit (and there would be the
big downside of Signals2 being a dependence of Synapse.)

Third, the two libraries take a different and incompatible approach to
thread safety. The connection list maintained by Signals2 signal objects
must be thread-safe, but the Synapse connection lists need not, since they
use thread_local storage. And, there is nothing in Signals2 that resembles
the interthread communication supported by Synapse (I do agree that the
ability to change the thread affinity of connection objects can be useful
and should probably be added to Synapse.)

This is not to say that there is anything wrong with Signals2. The search
Synapse must do when emit<S> is called could be a deal breaker in some use
cases. On the other hand Synapse makes emitting signals from a third-party
object simple and elegant.

Thanks,
Emil