apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: apr_mmap_t
Date Sun, 24 Nov 2002 16:24:46 GMT

> If you do change how the MMAP type works, I have a suggestion.  MMAP's are
> void *'s with size's, and that is the only way to really make sense of an
> MMAP.  Make the new structure something like:
>
> /* $(platform)_mmap_t are incomplete types implemented per OS */
> typedef union {
>     win_mmap_t *win;
>     unix_mmap_t *unix;
>     boes_mmap_t *beos;
> } apr_mmap_internal_t;
>
> struct apr_mmap_t {
>     apr_pool_t *p;
>     apr_mmap_internal_t *os_specific;
>     void *mm;
>     apr_size_t size;
>     int is_owner;   /* Is this still necessary? */
> }
>
> This gives all of the benefits of incomplete types (portability and
> maintainability), but it also opens the truly portable portions of the
> structure to the developer.  The goal with this design is to make the
> portable parts of APR portable, and the non-portable parts hidden.
>
> 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.

Another advantage to this model, is that it becomes simple to fold common
implementations into a single implementation.  We have a lot of duplicate
code in APR, because of the way the code is structured[1].


Ryan

1]  Back when I created the directory structure for APR, a lot of people
told me this would happen.  I didn't listen.  The duplicate code is my
fault, now I am trying to fix it.


Mime
View raw message