Re: [boost] [MMap/VM] RFC

Subject: Re: [boost] [MMap/VM] RFC
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2016-03-06 15:40:30

On 3.3.2016. 18:11, Mathias Gaunard wrote:
> I'm interested in the general idea of controlling virtual memory explicitly
> and portably.

That whas point 3 in the opening post.

>  From a quick look at the code, it seems to deal with the following aspects:
>   - map a file (not sure if anonymous is well supported)

Thanks for taking a look, however I'm not sure what do you mean by 
anonymous. Non-anonymous (i.e. named) file mappings exist natively only 
on Windows (point 5 from the opening post). However if you meant 
anonymous memory mappings then yes I did not cover those in the opening 
post. So let's 'name it' point 8:

8. Anonymous shared memory - memory shared between a parent and its 
child processes.
This one is still a todo item, mostly because I'm not yet sure how to 
model the discrepancy between the Windows and POSIX models. Both Windows 
and POSIX support inherited handles/descriptors for child processes 
(created with CreateProcess()/execve()), POSIX however also supports 
forking along with the corresponding MAP_ANONYMOUS mmap flag (i.e. 
anonymous virtual memory 'views').
So, one way is what Interprocess does now: use inherited handles on 
Windows and MAP_ANONYMOUS on POSIX - but this does not cover the case if 
someone wants handle/descriptor inheritance on POSIX systems too, and it 
also entails different ways of communicating the anonymous mapping 
'handle'/location between the processes on Windows vs POSIX systems.
Another way would be for anonymous_shared_memory to use the inherited 
handle/descriptor approach and to define a separate POSIX-only class 
anonymous_shared_memory_view used for the fork scenario. Unfortunately 
to me this only seems as a less ugly approach then the one above 
because, if the most often use case in crossplatform code is to use 
CreateProcess() on Windows and fork() on POSIX, it will still cause 
#ifdefs in user code...

> I'd like to have access to the following extended functionality:
>   - map at a fixed address

Still a todo item (again still figuring how to add the parameter to the 
API without exploding the number of overloads and/or forcing the user to 
specify it everywhere).

>   - actually allocate/free the pages

You mean like direct virtual memory management (i.e. the Win32 
VirtualAlloc* API)?

>   - map the same hardware page to multiple places in virtual memory without a
> file

You mean something like the 'magic ring buffer' example from point 3 
from the opening post?
Arbitrary remapping of just any address (even if page aligned) is AFAIK 
not possible on any of the major systems. I.e. you can map the same 
mappable object (shared memory or a file) at multiple locations (subject 
to 'allocation granularity') but you cannot for example make a 'virtual 
copy' of a std::vector (i.e. of memory allocated with malloc as opposed 
to memory allocated with mmap)...

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