Re: [boost] [interprocess][iostreams] trac#4234

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
news:4CB35BC2.5040302_at_extendedsubset.com...
> 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 
and Vista
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.
> http://msdn.microsoft.com/en-us/library/aa366907.aspx
> http://msdn.microsoft.com/en-us/library/aa366775.aspx
>
> 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 
cycles...

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