"Files must exist before being opened, and are never truncated; attempting to write past the end of a file results in an error. " This is quite restrictive, compared to the capabilities of posix mmap. Are these restrictions really necessary?
"Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:ch4qs2$npr$1@sea.gmane.org...
"Files must exist before being opened, and are never truncated; attempting to write past the end of a file results in an error. "
This is quite restrictive, compared to the capabilities of posix mmap. Are these restrictions really necessary?
I'm not an expert on memory mapped files. I basically redesigned the public interface but used Craig Henderson's implementation. I'd be happy to remove any or all of these restrictions, as long as it can be done for Windows and Posix. Could you be more specific about the missing functionality? I'll try to add it if it can be done portably. Jonathan
Jonathan Turkanis wrote:
"Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:ch4qs2$npr$1@sea.gmane.org...
"Files must exist before being opened, and are never truncated; attempting to write past the end of a file results in an error. "
This is quite restrictive, compared to the capabilities of posix mmap. Are these restrictions really necessary?
I'm not an expert on memory mapped files. I basically redesigned the public interface but used Craig Henderson's implementation. I'd be happy to remove any or all of these restrictions, as long as it can be done for Windows and Posix.
Could you be more specific about the missing functionality? I'll try to add it if it can be done portably.
After reviewing this, I think I spoke too soon. The above restrictions are consistent with Posix. I had thought that mmap would allow mapping beyond the file current size, but it seems not. One should use ftruncate to set the size before mmap instead. However, there is another point. IMHO, portable != lowest common denominator. Posix mmap supports various options, e.g., SHARED vs PRIVATE. I don't know what windows supports. I think a good selection of options should be available. If some platform doesn't support an option, it should either be ignored of an error. I think Python mmap module can (as always) serve as a good guide.
"Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:ch54na$m54$1@sea.gmane.org...
Jonathan Turkanis wrote:
After reviewing this, I think I spoke too soon. The above restrictions are consistent with Posix. I had thought that mmap would allow mapping beyond the file current size, but it seems not. One should use ftruncate to set the size before mmap instead.
However, there is another point.
IMHO, portable != lowest common denominator. Posix mmap supports various options, e.g., SHARED vs PRIVATE. I don't know what windows supports. I think a good selection of options should be available. If some platform doesn't support an option, it should either be ignored of an error. I think Python mmap module can (as always) serve as a good guide.
Okay. Craig's original implementation, IIRC, exposed protection and security settings, but there was no portable syntax. E.g., on windows flags_or_security_t was defined like this: typedef struct flags_or_security_ { DWORD access; LPSECURITY_ATTRIBUTES security; } flags_or_security_t; while on posix it was: typedef int flags_or_security_t; If you wanted to specify security settings, you'd have to use the native constants. (Craig, please correct me if I'm wrong.) I dropped this support for two reasons: - I didn't want to have to come up with a portable syntax, esp. since I am not expert in this area - Neither the standard library nor Boost.Filesystem exposes security or file-sharing options provided by the OS. If there's support for adding these features, it would seem appropriate to work on it after the review, and then request comments. Best Regards, Jonathan
participants (2)
-
Jonathan Turkanis -
Neal D. Becker