From: yirgster on 13 May 2010 14:14 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 13 May 2010 16:32 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 16 May 2010 07:51 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 17 May 2010 11:35 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 17 May 2010 12:36 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.
|
Next
|
Last
Pages: 1 2 Prev: New functional language - Fling Next: tutorial or guide to terminal settings? |