Closing memory-mapped files
Timothy Michel
I have a question regarding when is it "safe" to close the file handles
used when trying to memory-map a read-only file. The Win32 programmer's
reference (chap. 47) doesn't mention when to close the handles returned
by CreateFile or CreateFileMapping. It says that you will follow a sequence
as follows:
hFile = CreateFile(...);
hFileMap = CreateFileMapping(hFile,...);
lpvFile = MapViewOfFile(hFileMap,...);
UnmapViewOfFile(lpvFile);
When can you call CloseHandle(hFileMap) and CloseHandle(hFile)?
We have a DLL that opens dozens of read-only files via memory-mapping on both
Win32 and Win32s, and I'm afraid of running out of file descriptors in Win32s
if I don't close them. I know that you can increase the number of descriptors
available via SetHandleCount but this seems unnecessary and sets an artificial
limit.
The unix model for memory-map files says that it's safe to close the file
descriptor after calling the memory map function (mmap), as follows:
fd = open(...);
mptr = mmap(fd,...);
close (fd);
.
. (some other code)
.
munmap(mptr);
Stated in another way, I would like to do the following:
LPVOID MapFile(char *mapname)
{
HANDLE hFile, hFileMap;
LPVOID lpvFile;
hFile = CreateFile(mapname,GENERIC_READ,0,NULL,OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,NULL);
hFileMap = CreateFileMapping(hFile,NULL,PAGE_READONLY,0,0,NULL);
lpvFile = MapViewOfFile(hFileMap,FILE_MAP_READ,0,0,0);
CloseHandle(hFileMap);
CloseHandle(hFile);
return(lpvFile);
}
void UnmapFile(LPVOID lpvFile)
{
UnmapViewOfFile(lpvFile);
}
I've tried the above and it seems to work, however since none of this is
explicitly stated in any manual that I can find, I'm nervous about relying
on this behavior.
Any insight into this problem would be greatly appreciated.
Regards,
Tim Michel
tmi...@synopsys.com
Karl L. Barrus
>I have a question regarding when is it "safe" to close the file handles
>used when trying to memory-map a read-only file.
It is "safe" to close those handles when you are done with the handle. Unless you
plan on making extra file-mapping objects from the same file or mapping multiple views.
So you can even do something like this:
hFile = CreateFile();
hFileMapping = CreateFileMapping( hFile, ... );
CloseHandle( hFile );
pFile = MapViewOfFile( hFileMapping, ... );
CloseHandle( hFileMapping );
(Naturally, you may want some error checking in there, or maybe SEH)
I do this in an application I have and it works fine, and keeps down file object usage
counts.
Try Richter's "Advanced Windows: A Developer's Guide to the Win32 API for Windows NT
3.5 and Windows 95". Be careful, the first edition of the book looks similar and was
printed in NT 3.1 days. (It still has good info, but not the latest!)
Page 226 of the above book has an example of exactly what you want to do.
--
Karl L. Barrus
klba...@bangate.compaq.com
Roger Binns
: tmi...@hpxb1.pdxuxbre.lmc.com (Timothy Michel) wrote:
: >I have a question regarding when is it "safe" to close the file handles
: >used when trying to memory-map a read-only file.
: It is "safe" to close those handles when you are done with the handle. Unless you
: plan on making extra file-mapping objects from the same file or mapping multiple views.
Are the semantics that you used in CreateFile (particularly sharing
exclusivity) maintained after you close the file, but still have the view
`open'? I really wish the SDk would make these things clear!
Roger
--
__ __ __ __
| |\ / /| | Roger Binns | `Resurrection seems to have dubious
| | \/ / | | Software Engineer | utility to me. Why support it?'
| | / /\ | | IXI Ltd | -- be...@cs.ucdavis.edu
|__|/__/__\|__| Cambridge, UK rog...@x.co.uk
Karl L. Barrus
>exclusivity) maintained after you close the file, but still have the view
>`open'? I really wish the SDk would make these things clear!
Good question... I'm not sure about sharing exclusivity, but I just tested my program
by creating a file with FILE_ATTRIBUTE_READONLY, and also attempted to write to the
mapped view (after closing the handle to the file and file mapping)... and I got a big
"memory cannot be written" error. So it looks like the semantics are maintained.
Richter's book may have more information, but I don't have it handy today.
--
Karl L. Barrus <klba...@bangate.compaq.com>
2047/E7238031 : 0A 92 C4 F4 4A 27 05 1B 3A 0C CE 51 FE 5C 4F 02