apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: Opaque types [was apr_mmap_t]
Date Mon, 25 Nov 2002 03:07:54 GMT


On Sun, 24 Nov 2002, William A. Rowe, Jr. wrote:

> At 10:07 AM 11/24/2002, rbb@apache.org wrote:
>
> >Let me make myself clear.  I haven't expressed an opinion about whether
> >they should or should not be incomplete.  I have stated why incomplete
> >types were originally used in APR, namely for portability.
>
> Some of us interpreted (rightly or wrongly) that they benefit us in a number
> of ways.  There is more than one [right] opinion on this forum.

Understand something:  The original reason for using incomplete types
ISN'T an opinion.  It is a point of fact.  The reasons that we all like
them is an opinion, and I haven't said anything about that.

> >I have also said that having MMAPs be represented by anything other
> >than a void pointer and a size is a bit ludicrous.
>
> Then you clearly don't understand the implementation.
>
> Win32 must retrieve page-aligned file blocks.  That means that the real
> pointer to the mmap allocation is not the boundry the user requested,
> because we backspace to the last boundry when mapping the region.
> Then we give the user a pointer to their desired offset.
>
> Worse yet, the mmap is not the base kernel object.  All mmap's start
> their lives with a handle to a mapping.  With that handle to the mapping,
> we then map any desired pages into memory.
>
> So your offset/length assertion is, simply put, somewhat bogus.  We
> cannot even release the allocation given that original offset/length, on
> Win32 we must release the page-aligned region, then the mapping handle.
> I'll skip your other comments as they aren't germane to a portable mmap
> implementation.

No, it isn't bogus.  The simple fact is that to the application developer,
an MMAP is a void pointer and an offset.  Anything else that is in the
structure is baggage that the OS requires us to carry.  Shrink the MMAP
structure to what it REALLY means to the developer and hide everything
else.

< snipped the rest, I'll respond in a different message, to split MMAP
from future design>

Ryan



Mime
View raw message