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

On Fri, Dec 2, 2016 at 1:32 PM, Klaim - Joël Lamotte wrote:

On 2 December 2016 at 20:00, Nat Goodspeed wrote:

...

On Fri, Dec 2, 2016 at 1:31 PM, Emil Dotchevski 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