[Interprocess] Managed mapped file questions
Hi First of all, thank you for boost interprocess :-) I have a couple of questions: 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? 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? I'm asking this before sending any sample code or creating tickets, but of course I could do that as well if there is the need. Thanks again. Cheers Jorge
El 10/12/2012 21:15, Jorge Lodos Vigil escribió:
Hi First of all, thank you for boost interprocess :-)
I have a couple of questions:
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.
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). Best, Ion
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. Cheers Jorge
El 13/12/2012 2:28, Jorge Lodos Vigil escribió:
On 12/12/2012 7:07, Ion Gaztañaga wrote:
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?
I need to investigate it, but I tried to support similar behaviour for internal file-handling functions. I'll need to think it again. Please fill a ticket so this doesn't get lost when reviewing pending issues.
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.
Yes, that's the idea.
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 :-)
This seems a bug, please fill another ticket with your example. Ion
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
El 13/12/2012 2:28, Jorge Lodos Vigil escribió: perhaps don't affect platform portability. File portability between platforms should be warranted? What about platforms with different endianness? I just remembered that for initialization issues, at least the first bytes of the segment are supposed to be zero (POSIX guarantee) when first created. This zero value is used for some atomic operations to avoid racing conditions between simultaneous creation calls from different processes or threads. Maybe there is a way to guarantee the zero fill just for the first bytes of the underlying object and avoid it for the rest of the object. Best, Ion
participants (2)
-
Ion Gaztañaga -
Jorge Lodos Vigil