Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

msync() and MAP_PRIVATE

82 views
Skip to first unread message

yirgster

unread,
May 13, 2010, 2:14:36 PM5/13/10
to
The posix spec http://www.opengroup.org/onlinepubs/009695399/functions/msync.html
:

> It is unspecified whether data in MAP_PRIVATE mappings has any permanent storage locations.

So what are these "permanent storage locations". A tmp file in the
file system name space, that would be deleted upon system restart
seems the most likely candidate. (In fact, as I type this, I seem to
remember that this occurs in some os's.) Could it be other than a tmp
file?

Chris Friesen

unread,
May 13, 2010, 4:32:14 PM5/13/10
to
On 05/13/2010 12:14 PM, yirgster wrote:
> The posix spec http://www.opengroup.org/onlinepubs/009695399/functions/msync.html
> :
>
>> It is unspecified whether data in MAP_PRIVATE mappings has any permanent storage locations.
>
> So what are these "permanent storage locations".

An implementation could define a standard way to find the persistant
storage of MAP_PRIVATE mappings. This could be useful to allow them to
be persisted over reboots.

The wording is left open to allow this sort of extension. Likely most
implementations would simply ignore an msync() call on a private mapping.

Chris

Casper H.S. Dik

unread,
May 16, 2010, 7:51:34 AM5/16/10
to
yirgster <yirg....@gmail.com> writes:

It can't have a permanent storage location: the data is anonymous
because it private.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Chris Friesen

unread,
May 17, 2010, 11:35:09 AM5/17/10
to
On 05/16/2010 05:51 AM, Casper H.S. Dik wrote:
> yirgster <yirg....@gmail.com> writes:
>
>> The posix spec http://www.opengroup.org/onlinepubs/009695399/functions/msync.html
>> :
>
>>> It is unspecified whether data in MAP_PRIVATE mappings has any permanent storage locations.
>
>> So what are these "permanent storage locations". A tmp file in the
>> file system name space, that would be deleted upon system restart
>> seems the most likely candidate. (In fact, as I type this, I seem to
>> remember that this occurs in some os's.) Could it be other than a tmp
>> file?
>
> It can't have a permanent storage location: the data is anonymous
> because it private.

It is not true that it "can't" have such a location. The spec doesn't
mandate a storage location, but it doesn't say that they are forbidden
either. A conforming implementation could specify a storage location
for private mappings should it wish to do so.

Chris

Casper H.S. Dik

unread,
May 17, 2010, 12:36:10 PM5/17/10
to
Chris Friesen <cbf...@mail.usask.ca> writes:

Ah, but it is *private* so it is clearly it cannot be in the filesystem
space.

Chris Friesen

unread,
May 17, 2010, 1:02:48 PM5/17/10
to
On 05/17/2010 10:36 AM, Casper H.S. Dik wrote:
> Chris Friesen <cbf...@mail.usask.ca> writes:

>> It is not true that it "can't" have such a location. The spec doesn't
>> mandate a storage location, but it doesn't say that they are forbidden
>> either. A conforming implementation could specify a storage location
>> for private mappings should it wish to do so.
>
> Ah, but it is *private* so it is clearly it cannot be in the filesystem
> space.

Sure it can. Nothing says that the filesystem space has to be global.

It would be relatively straightforward to implement this using
per-process filesystem namespaces. Linux could do this now if anyone
wanted to do it.

Chris

0 new messages