Re: [boost] [interprocess, aka shmem] Some proposals for open issues from the review

From: Kim Barrett (kab_at_[hidden])
Date: 2006-02-28 19:38:08

At 5:50 PM +0100 2/28/06, Ion Gaztañaga wrote:
>The real space the user can overwrite is dependent on the "null" size of
>the memory algorithm and the null index. The compilation of all that
>structure for a user that just want to create a shared memory segment
>would be an overkill.
>
>I think that a simple shared_memory primitive (that just creates a
>segment and maps it) is useful because we have other operating system
>primitives (mapped file, mutex, semaphore).

At present the "simple" shared_memory already has a header region. I'm not
sure what is there, other than the reference count (which I need to follow
up on later). I haven't looked at mapped file in that regard.

>  > Both of these are attempting to get across the idea that the differentiator
>>  between them and the underlying primitive shared_memory, heap memory, ... is
>>  that these higher level constructs provide support for managing allocation
>>  from the raw block of memory.
>
>Yes, but it also allows anonymous object construction, named object
>construction and other features. I like "managed_shared_memory" because
>is shorter than other alternatives and compatible with the
>"segment_manager" concept. Any "managed_xxx" enemy out there?

I was thinking of the various kinds of object allocation and such as being
specific instances of the broad class of "managing allocation". I think
a relatively generic term is needed here because there are lots of different
detailed bits of functionality to be covered by the name.