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.


git-svn-id: http://svn.apache.org/repos/asf/apr/apr/trunk@62822 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 2 insertions, 16 deletions

diff --git a/shmem/win32/shm.c b/shmem/win32/shm.c
index 2fe26a0d9..754049067 100644
--- a/shmem/win32/shm.c
+++ b/shmem/win32/shm.c
@@ -143,29 +143,15 @@ APR_DECLARE(apr_status_t) apr_shm_create(apr_shm_t **m,
         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();