[wx-dev] Re: new class: wxMemoryMappedFile

[Vadim Zeitlin]

On Mon, 8 Jan 2007 15:10:37 +0000 (UTC) blake madden <blake.madden at oleandersolutions.com> wrote:

bm> Vadim Zeitlin <vadim at ...> writes:
bm> 
bm> >  Have you been able to find a satisfactory solution to the API problems we
bm> > discussed? I.e. what to do about different key/filename interpretation
bm> > between Windows and Unix, Also, does your class support mapping parts of
bm> > file and/or could it be extended to do it in the future? Please see the
bm> > thread at http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/81833/ for
bm> > details.
bm> 
bm> You just simply pass a file name into it and it maps it--all file
bm> descriptor/handle logic is abstracted.

 So it can't be used without underlying (physical) file?

bm> I don't do anything in here except for files because (at least IMHO)
bm> it's better to maybe make a separate class(es) later on for shared
bm> memory or devices and keep this class as simple as possible.  

 I don't disagree with the idea of having a separate wxSharedMemory class
but it would clearly share a lot of code with this one so we need to have a
common base class or some other way to avoid code duplication in this case.

bm> Currently it simply maps the entire file, that seems to be what most
bm> people want to do.  I experimented once to try mapping sections of a
bm> file, but I remember the Windows API always returns a pointer to all of
bm> the file's content (despite only part of it being really mapped). That
bm> can be really confusing.

 I'm not sure about this. In any case, mapping part of a file is really
useful, sometimes you may be only interested in a single frame of a huge
video file for example.

bm> My concern is how dangerous only mapping part of a file can be, I think
bm> even MSDN warns you about this.

 I'd be interested in a reference about this.


bm> >  This is nice but we already have wxFileOffset and I think it should be
bm> > used here instead.
bm> 
bm> Sorry, I misspoke on this point.
bm> It returns a size_t on both platforms.  Now that I remember, the API on
bm> UNIX and Windows can map files at maximum of 2Gbs chunks, so for huge
bm> files I guess you would need to somehow map the file into "slices".

 This is definitely not true for Windows where CreateFileMapping() takes 2
DWORDs to specify the size of the mapping. And I suspect it's also possible
to map more than 4GB under Unix too. And the offset can, of course, be more
than 4GB in both Windows (MapViewOfFile() also takes 2 DWORDs) and Unix
(off_t argument of mmap() can be 64 bit).

 Regards,
VZ