Subject: Re: [boost] [Interprocess] Managed mapped file questions
From: Jorge Lodos Vigil (lodos_at_[hidden])
Date: 2012-12-12 20:28:29
On 12/12/2012 7:07, Ion Gaztañaga wrote:
> > 1. When you grow a managed mapped file, the current
> > implementation fills all the new space with zeroes. This is less
> > efficient than just resizing the file. The comments in the code
> > implies there is a reason, so what is it?
> Interprocess tries to simulate as much as possible POSIX guarantees.
> truncate() POSIX system call guarantees that "If the file is extended,
> the extended area appears as if it were zero-filled". In windows,
> SetFileValidData/SetEndOfFile does not zero-fill the extended size so
> Interprocess needs to write it.
Given that the mapped file content is not part of the library interface, and the only expected user of the mapped file is the library itself, why waste time in Windows? Seems to me that a requirement that files should be identical is too strong, as long as they work and perhaps don't affect platform portability. File portability between platforms should be warranted? What about platforms with different endianness?
> > 2. When the size to map is too small, take 1 or 2 bytes for
> > instance, the library fails in a non elegant way. This is a corner
> > case, but I could not find this documented. Is this a bug?
> You need a minimum size to construct managed memory's internal
> structures. Maybe the behaviour should be documented. What do you mean
> with "non-elegant", your application crashses? Nevertheless, mapping 1
> or 2 bytes you waste resources, as the OS will map at least one page
> (4K on most 32 bit systems and 64 K on Windows).
Yes, the application crashes. I am mapping large complex containers with different sizes, the crashes took place when I was developing tests. I would expect an exception when the size of the mapping is not enough.
It is time consuming to develop a structure that would need more than 4Kb for its initial mapping. if I create a ticket with a sample using a few bytes just to demonstrate the problem, would you consider it? I understand this is not a show stopper :-)
Thank you for your answers and again for boost::interprocess.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk