wrowe 02/01/23 23:45:36
Modified: shmem/win32 shm.c
Log:
Problem resolved; how exactly I'm not certain, but we have no faults
creating either anon or named memory now.
Of course, reattaching a detached processes anon handle requires some
further efforts. An apr_shm_os_get/put should help.
Revision Changes Path
1.6 +2 -16 apr/shmem/win32/shm.c
Index: shm.c
===================================================================
RCS file: /home/cvs/apr/shmem/win32/shm.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- shm.c 11 Jan 2002 08:30:55 -0000 1.5
+++ shm.c 24 Jan 2002 07:45:36 -0000 1.6
@@ -143,29 +143,15 @@
psec = NULL;
}
- /* XXX: I had nothing but utter failure on WinNT attempting to specify
- * the size of the CreateFileMapping() calls below (given in DWORDs
- * as hi-DWORD, lo-DWORD where you see the 0, 0 args.) Consistently,
- * Win2K reported insufficient disk space, when that is obviously not
- * the case. I'm suspecting size should have been in pages (???) but
- * there was no docs in the PSDK that made that implication.
- *
- * The XXX above is due to the fact that anon allocation dies right now,
- * since we can't create a filemapping with size zero, when we don't
- * back it with a file. Since I clearly don't understand what Win32
- * has done with this size arg, I'm loath to make the obvious fix.
- * Let it fail until I, or someone with time on their hands, wants to
- * research, experiment and fix this for good.
- */
#if APR_HAS_UNICODE_FS
if (apr_os_level >= APR_WIN_NT)
{
- hMap = CreateFileMappingW(hFile, psec, PAGE_READWRITE, 0, 0, mapkey);
+ hMap = CreateFileMappingW(hFile, psec, PAGE_READWRITE, 0, size,
mapkey);
}
else
#endif
{
- hMap = CreateFileMappingA(hFile, psec, PAGE_READWRITE, 0, 0, mapkey);
+ hMap = CreateFileMappingA(hFile, psec, PAGE_READWRITE, 0, size,
mapkey);
}
err = apr_get_os_error();
