Re: [boost] Re: Testing interest for a shared memory/STL library proposal

From: Ion Gaztañaga (ion_g_m_at_[hidden])
Date: 2004-11-10 12:19:01

>>From what I can gather from the docs, then the required changed to the
> standard library
> is quite small; maybe you should consider submitting a defect report that 
> says
> where the standard
> must be changed in order to support this style of allocators and 
> allocation?
>
> Rewriting all container classes seems to be a quite big task, so maybe its
> better to change the standard.

Yes, I agree that would be nice and it is the way to go. Some 
implementations, such as Dinkum STL use allocator::pointer as pointer type 
and they have very minor problems compiling this approach.

What I want to make clear is that I don't want to reinvent the STL for 
boost. I was talking to boostify only helper classes so that I could for 
example write in one process:

//-----------------------------------------------------------------

//Create shared memory allocator segment
shm_named_alloc segment
segment.create("/MyShMem", 10000);

//Create an array of ints named "MyInts" in shared memory segment 
"/MyShaMem"
int *ptr = segment.named_alloc<int>("MyInts", 10/*allocate an array*/, 
0/*ctor parameter*/)

//Fill ints
for(int i = 0, i < 10){
    ptr[i] = i;
}
std::fill(ptr, ptr+10, 1);

And in other process write:

//-----------------------------------------------------------------

shm_named_alloc segment

//Open allocator
segment.open("/MyShMem", 10000);

//Find "MyInts"
int *ptr = segment.named_find<int>("MyInts")

//sort
std::sort(ptr, ptr+10);

//Delete "MyInts" array from segment
segment.named_delete<int>("MyInts");

//-----------------------------------------------------------------

To get this, I propose a library with the following classes:

-> Relative pointer (a new smart pointer).
-> shared memory creation class, process shared mutex,  process shared 
reentrant mutex, named semaphore
-> shared memory manager class (uses shared memory segment as a pool for 
allowing malloc/free like operations)
-> named shared memory manager (so that the user can store any class 
associated with a name in the shared memory segment)
-> a STL allocator providing shared memory allocator for STL-like containers

If someone wants to create its own container can use these elements but I 
don't plan to repeat all standard containers for boost. But I think that 
placing classes in shared memory can be interesting for efficient 
inter-process communication.

Maybe I've not explained very well my goals. My article is about STL 
containers, but my proposal is for placing any object in shared memory and 
provide some allocators (normal and pooled) so that users can create their 
own containers if they need that.

I hope this explanation can correct my previous post.

Regards,

Ion