From: yirgster on
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?
From: Chris Friesen on
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
From: Casper H.S. Dik on
yirgster <yirg.kenya(a)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.

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.
From: Chris Friesen on
On 05/16/2010 05:51 AM, Casper H.S. Dik wrote:
> yirgster <yirg.kenya(a)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
From: Casper H.S. Dik on
Chris Friesen <cbf123(a)mail.usask.ca> writes:

>On 05/16/2010 05:51 AM, Casper H.S. Dik wrote:
>> yirgster <yirg.kenya(a)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.

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

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.