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-04 18:49:35

On Sun, Dec 4, 2016 at 2:51 PM, Robert McInnis <r_mcinnis_at_[hidden]>
wrote:

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Emil
> Dotchevski
> Sent: Sunday, December 04, 2016 5:45 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Synapse library review starts today December 2
>
> Emil said:
> >
> > >      - What is your evaluation of the potential usefulness of the
> > >>        library?
> > >>
> > > I don't think it's that useful, but I guess I would still use
> > > boost.signals2 and boost::asio::io_service for interthread signaling.
> > > I'm not convinced this should be a distinct library, and not a feature
> > > of boost.signals2.
> > >
> >
> > Synapse does not claim to be a "better" Signals2; its usefulness is not
> as
> an alternative
> > to Signals2 but as a solution to problems Signals2 cannot solve. Here are
> three examples
> > of this, though I have many more:
> >
> >
> http://zajo.github.io/boost-synapse/handling_events_from_
> an_OS_message_pump.
> html
> >
> http://zajo.github.io/boost-synapse/adding_custom_signals_
> to_Qt_objects_with
> out_MOCing.html
> >
> http://zajo.github.io/boost-synapse/using_meta_signals_to_
> connect_to_a_C-sty
> le_callback_API.html
>
> I disagree with this design style, which is to say I also disagree with the
> existing slot/signal style.
>
> As an example, what if we had a system with hundreds of thousands of
> numerics... each with a particular
> name.  Then imagine a rule set that had to maintain integrity as any
> particular numeric were to be
> changed.  With slots or synapses, you're forced to search for the object
> each time before applying the
> rules.  This would bog down quickly as the number of updates per second
> increased (imagine 100k objects
> and 2-10k entwined rules being updated 2k times per second.  That's a real
> world scenario)
>

The search is the price one has to pay for the non-intrusive nature of
Synapse. Obviously, when this isn't necessary (and the overhead of the
search is significant, as in the real world use case you're referring to)
then you can use a different approach.

That said, in my own use cases the overhead of Synapse has never been
significant in comparison to the time it takes to execute the actual
connected functions. Note that the search is limited only to connections of
the same signal type, and that it can be implemented as a hash, O(1).

Objects should have events they can trigger or subjects they contain/manage
> which would trigger
> given a certain situation (value changes, particular event arrives, flag
> flips, whatever) and the
> observer(s), being unknown to the original object, would observe the event
> via a loose coupling
> mechanism.
>
> This allows for a system to have hundreds or thousands of objects all
> trigging events at random but
> only notifying the particular observers that are interested in that
> instance's event.
>
> This allows for a more flexible system while promoting dependency driven
> updates... which would
> result in the best performance for an event notification system.
>
> I've been using such a design since 1990 and posted a rendition of it to
> this group 3 months ago:
>
> https://github.com/tiny/boost_observers
>

You should request a formal review, if the Boost community finds your
library useful it'll be accepted.

Emil