Buenos días Vicenç,
Te envío la respuesta del desarrollador de la librería.
Tiene sentido lo que dice. La única pega, quizás, sería que, en caso de no haber memoria disponible, tardaríamos al menos tanto tiempo como el "round-trip latency" antes de darnos cuenta...
Un saludo,
Jorge
> Message: 1
> Date: Thu, 03 Jul 2014 20:08:33 +0200
> From: Ion Gazta?aga <igaztanaga@gmail.com>
> To: boost-users@lists.boost.org
> Subject: Re: [Boost-users] [Interprocess] Managed segment placement
> Message-ID: <53B59C21.9040901@gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> El 03/07/2014 10:24, Jorge Bellon escribi?:
> > Hi Ion,
> > Thank you for the info.
> >
> > The use case would be to manage a memory pool allocated on a remote node.
> >
> > This would be used by a run-time library for distributed programming. It
> > would allocate a memory region and manage this memory from another node,
> > so that we can perform operations with that piece of memory (allocate
> > portions, transfer data, etc.) without the intervention of the local
> > node.
>
> Why can't you put the manager in the remote node? The manager also needs
> to allocate memory for indexes that track the position of named/unique
> objects and that memory comes from the memory region also used to
> construct objects. If you don't need named objects you can use a null
> index to minimize used memory.
>
> Do you need to shared this remote node memory between processes? If you
> only use remote memory from a single process you can speed things a bit
> using raw pointers:
>
> typedef basic_managed_external_buffer <
> char,
> rbtree_best_fit<null_mutex_family, void* >,
> null_index
>
> > my_managed_external_buffer;
>
> If you want to serialize objects then you should use offset_ptr<void>
> instead of void*.
>
> I still miss the point of separating the manager (which is placed in the
> beginning of the memory region) and the rest of the region.
>
> Best,
>
> Ion