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 05:51:49 GMT

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

> At 09:24 PM 11/24/2002, rbb@apache.org wrote:
> >> 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
> >
> >There are very few compilers that can inline functions that are in
> >separate libraries.  In fact, I don't currently know of any.
> Of course, there are none that inline functions in libraries.  inline functions
> need to exist in headers.  We might end up with a scenario such as...
> apr_mmap.h  [public header]
>   #include "apr.h"
>   /* Incomplete type */
>   typedef struct apr_mmap_t apr_mmap_t;
>   /* Prototype */
>   APR_DECLARE_INLINE(footype) apr_mmap_foo_get(apr_mmap_t *mmap);
>   # include "apr_mmap_inline.h"
>   #endif
> apr_mmap_inline.h
>   /* This private header is included for inline declarations.
>    * use of the embedded structures binds your application
>    * to this specific build of APR.  These structures are subject
>    * to change without warning. */
>   struct apr_mmap_t {
>     footype foo; ...
>   } apr_mmap_t;
>   /* Implementation */
>   APR_DECLARE_INLINE(typefoo) apr_mmap_foo_get(apr_mmap_t *mmap) {
>   }
> mmap_inline.c
>   #undef APR_USE_INLINE
>   #include "apr_mmap.h"
>   /* capture inline functions as exported real functions */
>   #include "apr_mmap_inline.h"
> mmap.c
>   #define APR_USE_INLINE  /* if it's not simply global */
>   #include "apr_mmap.h"
>   APR_DECLARE(apr_status_t) apr_mmap_create(...) {
>     ...
>   }
> Obviously, this is skeletal.  It provides that all functions are exported,
> and some simple functions may be inlined.

I tried to snip some of this, but I couldn't.  This is bogus.  Your header
with the inline header needs information that is private to the APR
internals.  That means that it can never be included from any file that is
public.  At the end of the day, what you are describing above is
completely impossible.

> >> 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.
> >
> >I can't understand this statement at all.  Deployment across different
> >platforms doesn't make sense in APR.
> Sorry, wrong phrase.  Different target machines.  Think binary builds of
> packages, where the package doesn't distribute APR, but presumes it
> will be installed on the machine.  Binary compatibility to the inlines would
> never fly, so that package builds without APR_USE_INLINE, for example.
> Anyone building the package to include the specific release of APR would
> use inline, of course.

As I said above, your whole inlining concept won't work.  You are trying
to get private data to public headers, which can't happen.

> >> By committing to unwrapping all of the opaque types, you seem hell
> >> bent on ensuring we forever break binary compatibility.  Opaque types
> >
> >Again, what in the world are you talking about?  The design that I
> >suggested actually makes binary compatibility one of it's core goals.  I
> >am a VERY strong believer in binary compat for libraries, so this
> >statement makes little to no sense.  If you look at the design, you will
> >see that it splits the structure into two parts:  1)  The logical
> >component and 2)  The OS specific component.  Because there is an
> >incomplete type in the middle of the structure, an allocator is still
> >required to actually create an instance of a type.  That means that binary
> >compat is easy to get, assuming all new fields are added at the end of the
> >structure.  The only time you will get into trouble is if somebody passes
> >the structure itself instead of a pointer to the structure.  Yes, binary
> >compat would be broken between 1.0 and 2.0, but we never said that was a
> >goal.
> I don't believe what you suggest is portable.  Of course my VC is very happy
> to parse a struct def with a pointer to an incomplete type anywhere within
> the structure, or an undefined array at the *end* of the structure.  But since

Will, please, that is just completely bogus.  Are you honestly telling me
that you believe that there is a compiler that doesn't know how to put a
pointer to an incomplete type inside of a structure?  If so, then Apache
2.0 isn't portable to that platform.  What I am suggesting is 100%
identical to what Apache does by putting an apr_file_t inside the
request_rec.  Add to that, we are ALREADY doing what I suggest, this model
was used in apr_poll_t, and it works just find.

I am not going to respond to the rest of this message, it is nothing but
flame bait.

> Let me close by offering that we *better* not find out you are responding
> to list messages while waiting in the delivery room/suite :-)  We can pick
> up the dialog after you get back.  God bless the three of you :-)

We are still waiting for the real labor to begin.  I has been two days,
and I am wasting time on the computer.


View raw message