> From: Greg Stein [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 07, 2000 2:09 AM > > > wrowe 00/12/06 22:58:59 > > > > --- apr_mmap.h 2000/12/07 05:00:27 1.18 > > +++ apr_mmap.h 2000/12/07 06:58:59 1.19 > > @@ -90,6 +90,16 @@ > > /** An area ID. Only valid on BeOS */ > > area_id area; > > #endif > > +#ifdef WIN32 > > + /** The handle of the file mapping */ > > + HANDLE mhandle; > > + /** The start of the real memory page area (mapped view) */ > > + void *mv; > > + /** The physical start, size and offset */ > > + size_t pstart; > > + size_t psize; > > + size_t poffset; > > +#endif > > Non-win32-specific question: why is the MMAP structure > visible? Shouldn't that be an opaque structure?
rbb and I agreed last night, except that there are some optimizations that go away with hiding the type (contrawise, common.c code should be macros, if this type remains visible.) We left it for you to find :-) > >... > > #include "apr.h" > > #include "apr_private.h" > > #include "apr_general.h" > > #include "apr_mmap.h" > > #include "apr_errno.h" > > #include "fileio.h" > > #include "apr_portable.h" > > > > #if APR_HAS_MMAP > > Why put this in here? apr_private.hw defines it to 1. The above statement > seems to imply that sometimes it will be non-zero. And that just isn't the > case... Because I always leave the option to -quickly- yank new code. The new filename canonical will go into the server first before Sunday night, and will retain (for now) a bunch of extra cruft in the non-canonical compilation path. This test could go away whenever. The other reason it's left is to remember that it isn't tested on all win platforms, and we know that the Win32 API discrepancies are worse than five releases of three different ports of Unix.
