apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <rbl...@gmail.com>
Subject Re-architecture for 2.0 tree
Date Wed, 19 Jan 2005 18:33:14 GMT
Those of you who have been here for a long time have heard me talking
about this idea,  but I wanted to get it out there for everybody and
on list.  Obviously, I probably won't implement much of it, but I
would like people to think about it.  This is a 2.0 change, because it
completely changes the source and binary compatibility of APR.

One of my biggest mistakes when initially designing APR was that I
forced each platform to have completely distinct implementations for
simple functions if the structures were distinct.  This has led to a
great amount of duplicate code in the library, and makes it harder to
see where the differences between the platforms truly are.  I would
love to see APR 2.0 solve this problem.

My idea is simple enough, share as much of the structures as possible
between platforms.  This allows the functions that act on those
structures to be common code.  To do this, the basic format of our
structures have to change, so that they look more like the apr_poll_t
structure.  I'll use files as an example (forgive the syntax):

typedef struct arch_file arch_file;
typedef struct apr_file_t {
    apr_pool_t *p;
    char *name;
    int eof_hit;
    ....
    union 
    apr_arch_file_t *arch_file;
} apr_file_t;

In another header file:
#ifdef WIN32
struct arch_file {
    HANDLE filedes;
}
#else
struct arch_file {
    int filedes;
}
#endif

This should be enough that you can see what I am thinking about. 
Basically, anything that is common to all files is in a shared
structure which can be incomplete, but doesn't have to be.  Anything
that isn't common is stuck in an internal structure, which must be
incomplete.  This can allow simple functions, like
apr_file_get_name(), to read the name of the file quickly (and only
have one implementation of that function), while still allowing native
functions to be used for the more complex work.

If we don't want the apr_file_t structure to be incomplete, we can
still provide the getters/setters for the internal structures, but
also open up our structures, so that people can get the file's name by
accessing fp->name directly.

This may also help us remove the depenance on pools throughout the
code.  My least favorite part of APR is that all allocation _must_ be
done through pools, even if pools don't make sense for your
application (I take full blame for that).  With this model, end-users
can allocate the space for apr_file_t themselves, and all we need to
do is figure out how to allocate the arch_file structure correctly, a
much smaller allocation, and I believe we will find that we allocate
less within APR and allow developers to pass us pre-allocated
structures.

Thoughts, comments, critisms, questions?

Ryan

-- 
Ryan Bloom
rbb@apache.org
rbb@redhat.com
rbloom@gmail.com

Mime
View raw message