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

Subject: [boost] [interprocess] sharing memory between 32 bit and 64 bit Windows processes
From: Arno Schödl (aschoedl_at_[hidden])
Date: 2011-02-23 04:54:15

> > We'd implement it, as long as you are willing to review it and allow it into boost.

> Don't worry, I'll review it,

Hello Ion,

there is a design decision to make w.r.t. mixing 32 bit and 64 bit environments:

- In a mixed environment, each shared heap can be no larger than 32 bit.
- offset_ptr must have the ability to point to any place _in any of potentially many heaps_ because at the time of dereferencing it has no information about the heap it is meant to point to. This requires a heap-relative 32 bit quantity plus some "heap selector", or a this-relative 64 bit quantity. The latter is simple, fast and not significantly less compact than the former, so we pick the latter.
- Option 1: For the rest of the code, the easiest option is to make everything 64 bit, e.g., deriving size_type et. al. from offset_ptr. Unfortunately, this makes all interfaces 64 bit. So even on 32 bit you can request a 64 bit shared heap. Internally, when going to the OS to allocate the heap, there is a cast to 32-bit size_t with data loss, which is ugly.
- Option 2: So the interfaces should really be 32 bit on both 32 bit and 64 bit. This would require a second template parameter size_type for the MemoryAlgorithm, in addition to the pointer type. We can then migrate parts of the code to use this 32 bit quantity as much as possible for compactness. I think this Option 2 is safer and philosophically closer to what is really going on.

What do you prefer?

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