Subject: Re: [boost] [interprocess][iostreams] trac#4234
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2010-10-19 11:28:24
"Marsh Ray" <marsh_at_[hidden]> wrote in message
> On 10/10/2010 08:31 PM, Domagoj Saric wrote:
>> - AFAIK the POSIX 'anonymous
>> inheritable' shared memory functionality is also available on Win32
>> - kernel-life time shared memory emulation with memory mapped files on
>> Windows is also unnecessary. It can be either provided directly by
>> bypassing the Win32 APIs using the native NT API (I volunteer to help
>> with the implementation or can do it from scratch by myself)
> Be aware that native API calls are not always documented and are subject
> to change.
I'm aware of that, however considering that:
- Interprocess already uses the native NT API
- interdependencies between Microsoft's/Windows' own components (and the
sheer number of those) make it reasonable to assume breaking changes to the
native NT API can in practice ever occur only between major OS releases
- in practice breaking changes to system APIs have to be expected between
major OS releases even for Win32 and other 'old&public' API as was
demonstrated for example by the changes for interactive services between XP
I'd consider this 'danger' practically irrelevant (more like 'academic/by
the book paranoia')...especially considering the convenience and efficiency
benefits the native NT API gives over Win32...
>> AFAICT the only thing the Win32 API lacks for this is
>> getting the size of the mapped region which could perhaps be emulated
>> by passing the size at the begining of the mapped region...
> You might be able to do something with VirtualQueryEx, it fills in a
> MEMORY_BASIC_INFORMATION structure about a specified address.
> This gives the base address and size of the page range with the same
> attributes. You can walk through the regions (I wouldn't assume that it's
> always going to be reported as one contiguous range) and total up the
> pages with the MEM_MAPPED type ("Indicates that the memory pages within
> the region are mapped into the view of a section.").
> Just to ensure another mapped view isn't placed immediately after it, you
> might want to make a sort of guard page (with VirtualAllocEx) having some
> non-MEM_MAPPED type right at the end of the mapped view.
Right! Thanks for the idea ;-)
This could be used for a 'backup' (Win32 based) implementation for Windows
(that can be used/selected for Windows targets that do not have an
underlying native API, if such exist, maybe WinCE...)...
All in all, native or otherwise, the proposed changes (independent of the
efficiency issues and changes that started all this) seem rather logical as
they would make Boost.Interprocess more crossplatform-like...True they would
break backward compatibility but I'd consider that well worth it...after all
backward compatibility wrappers can always be provided for a few version
Ion, what's your take on this?
-- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk