apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Opaque types [was apr_mmap_t]
Date Sun, 24 Nov 2002 23:32:53 GMT
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.

>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.

>I thought of this a few months ago, but I have been sitting on it while we
>try to get 1.0 out the door.  This is my vision for how APR 2.0 will be
>implemented (I was going to propose it to the list after 1.0 had been
>released).  This makes the API cleaner and smaller, because many of the
>accessor functions can cleanly be deprecated (Think all of the userdata
>functions).  It also solves a lot of problems with apr_proc_t's on
>Windows, where we don't have anyplace to store OS specific information.
>
>When I said a few days ago that I had hoped that many of the incomplete
>types would go away in APR 2.0, this is what I meant.  I don't think we
>should re-write APR 1.0 now, but if you are going to change MMAPs, then
>please let's do it the right way.

Your "one right way" seems to be at odds with other's interpretations.

I'm not arguing that exposing incomplete types wouldn't speed up APR.
In fact, well written accessors that are inline'able on all modern compilers
would be a beautiful thing.  They would work only for 'private' copies of
the apr library, since the app becomes permanently bound to the explicit
version installed at the time you build it.  That would be fine by httpd and
other consumers who don't mind building APR themselves, or for apps
that are built via one of the packaging tools that tracks dependencies,
and will rebuild the entire slew of dependent packages when a new 
version of APR is installed.

Of course, this won't work for deployment across different platforms.
By committing to unwrapping all of the opaque types, you seem hell
bent on ensuring we forever break binary compatibility.  Opaque types
are goodness for versioning, portability, and extensions of the APR
library to other languages (e.g. tcl, perl, java etc, especially those
with OO schemas).  We (you especially) did a passable job of making
APR map very well to OO schemas.  Please consider their benefits 
of opaque types before we make plans to wipe them out.

Bill


Mime
View raw message