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-03 02:25:41

On Fri, Dec 2, 2016 at 1:32 PM, Klaim - Joël Lamotte <mjklaim_at_[hidden]>
wrote:

> On 2 December 2016 at 20:00, Nat Goodspeed <nat_at_[hidden]> wrote:
>
> > On Fri, Dec 2, 2016 at 1:31 PM, Emil Dotchevski
> > <emildotchevski_at_[hidden]> wrote:
> >
> > > See http://zajo.github.io/boost-synapse/questions_and_answers.html.
> >
> > Thanks.
> >
> > > In Synapse the emitter is simply a "meeting place": using emit<foo>(p)
> to
> > > emit the signal foo from the object p will call any functions that were
> > > connected by connect<foo>(p,f), where p is simply (the address of) any
> > > object (of any type whatsoever) you have in your program.
> >
> > So, the library contains something like a thread_local unordered_map
> > whose keys are arbitrary pointers?
> >
> >
>
> Last time I checked, it was a static map if I remember correctly, inside a
> function.
>
While I like the basic idea of Synapse, I do not like that I do not have
> any control as to where the observers are stored.
> It was my only complain at the initial presentation of the library.
>
> I didn't have time yet to look at this version of the library (I will
> soon), but basically if it could
> let me add an optional parametter to the connect so that I provide the
> storage (which lifetime and maybe implementtion I would guarantee myself),
> it would allow me to control allocations of these stored connections.
>

The current implementation uses a thread_local std::vector per signal type
for memory, though the connection records are organized in a linked list in
that vector, maintaining a list of the free nodes so elements of the vector
are reused (in Synapse, the connected functions are called in the order
they were connected.) There are additional dynamic allocations in the
presence of thread local queues (see interthread communication.)

The bottom line is that the data structures are very intricate (some use
thread_local storage, some use static objects, some are per signal type,
some are managed by shared_ptr for thread-safe control of their lifetime)
and I believe it would be pretty difficult to allow for user-defined
allocations. Perhaps it's possible.

Emil