|
Boost : |
Subject: [boost] [interprocess] sharing memory between 32 bit and 64 bit Windows processes
From: Arno Schödl (aschoedl_at_[hidden])
Date: 2011-02-24 03:37:16
Hello Ion,
> - 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.
- Option 3: Actually, the right solution is to make offset_ptr::difference_type of a mixed-environment offset pointer 32 bit, but its internal offset representation 64 bit. So all shared size_types and difference_types will be 32 bit, which is correct because all array sizes and differences between pointers within arrays are limited to 32 bit. For those places where internal algorithms (such as the rbtree memory algorithm) need modulo arithmetic, we will make a custom typedef in offset_ptr to export the "virtual address space size".
Any objection? It would be great if you could give us feedback, because we want to get done with that stuff, we need it badly...
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 +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk