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: Arno Schödl (aschoedl_at_[hidden])
Date: 2011-02-24 12:46:27

> 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.

Actually, it would try to allocate 4096MB+16MB, truncated to 16MB, which would succeed.
I think any shared memory user either has to support 32 bit clients, and thus
has to accommodate them, or not. Then compile-time checks and more compact
structures due to smaller size_type/difference_type are better than
runtime errors. We will BOOST_STATIC_ASSERT that offset_ptr::difference_type
cannot be larger than ptrdiff_t.

You can allow the runtime choice if you see the need. I currently don't.

> > 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.

> 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 ;-)

That's exactly what we did. The unit tests pass.
We'll do some more checks, also looking at the compiler warnings 
for truncation so we can justify every lossy cast we added (very few),
and then you'll get the patch.

Thanks!

Arno

--
Dr. Arno Schödl | aschoedl_at_[hidden]
Technical Director
think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany
http://www.think-cell.com | phone [phone] | US phone [phone]
Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306
Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl