Re: [boost] [interprocess] sharing memory between 32 bit and 64 bit Windows processes

Subject: Re: [boost] [interprocess] sharing memory between 32 bit and 64 bit Windows processes
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-02-24 12:02:57

El 24/02/2011 15:10, Arno Schödl escribió:
> Hello Ion,
> Option 1: Say the requested size is 0x101000000 (4GB+16MB), for
> example. 32 bit OS would truncate that to 0x1000000 and all
> allocation/memory mapping calls would succeed (if you have 16MB to
> spare). Other internal datastructures being 64 bit, they would be set
> up to show the full 4GB+16MB. This wouldn't work.

I can't see how a 32 bit OS could request 4016MB without detecting the 
overflow. The managed_shared_memory interface should take std::size_t as 
size. If the user truncates a 64 bit value to size_t the compiler should 
issue a warning, it's not interprocess' problem. When connecting to an 
existing shared memory, the OS should detect the overflow and issue an 
error if trying to connect a shared memory bigger than 32 bit. 
mapped_region does this for windows but the check is missing in UNIX (we 
need to check the return of fstat()-> st_size to be less than the 
maximum value of std::size_t). I'll add this.

> Option 3: The offset_ptr itself must be 64 bit, no question. But its
> size_type/difference_type do not have to be able to hold the
> difference between two arbitrary pointers, just between two pointers
> to the same memory block, which is max 32 bit:

Ok, I missed that. I guess that if shared memory is less than 32 bits, 
then this would work.

I think we should support both approaches: we should be able to use a 64 
bit wide smart pointer that can define size_type and difference_type 
with different types (I guess we could impose size_type to be the 
unsigned version of difference_type). Offset_ptr should be the 
customization point for addressing options: memory algorithms and 
allocators get the addresing configuration from the pointer type, and 
containers should take the configuration from allocators. Thanks we have 
templates in the language ;-)

Best,

Ion