Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at