[boost] Re: IOStream mmap too restrictive?

From: Jonathan Graehl (jonathan_at_[hidden])
Date: 2004-09-01 20:56:21

>
>
>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.
>

Since ftruncate isn't portable, it seems something like this (warning: 
untested) would be appropriate for boost::filesystem (perhaps taking a 
path object as an argument instead of a string - and shouldn't the Boost 
IO library do the same?)

#ifdef _WIN32
#include <io.h>
#else
#include <unistd.h>
#endif

bool create_file(const std::string& path,std::size_t size) {
#ifdef _WIN32
    int fh=::_open(path.c_str(),_O_CREAT|_O_SHORT_LIVED);
    if (fh == -1)
        return false;
    if (::_chsize(fh,size) == -1)
        return false;
    return ::_close(fh) != -1;
#else
    return ::truncate(path.c_str(),size) != -1;
#endif
}

I don't see how, in Windows, to atomically keep the file open before 
it's mmapped, because chsize takes an int fh and the (equivalent of) 
mmap takes a HANDLE (maybe there is some Win32 call to get the HANDLE 
from the int fh?).  The abstraction/interface that seems to be missing 
here is a low level (operating system level) file descriptor that can be 
passed to platform specific functions like ftruncate or _chsize, which 
weren't anticipated and wrapped by the higher-level libraries.

I'd also like to see a constructor for mapped_file that creates a new 
file of exactly the required size (this might be a reasonable request 
for mapped_file_sink as well).  It might also be nice to be able to set 
MAP_SHARED vs MAP_PRIVATE, or to be allowed to atomically deactivate an 
existing mapped_file (substituting a new backing file), guaranteeing the 
same address space (this is, I think, feasible if you do no allocation 
between munmap and mmap, and you can always detect failure by setting 
MAP_FIXED).

I guess there's enough work left to be done for a "proper" Windows/POSIX 
mmap wrapper that the IO library shouldn't attempt to promote it yet.