apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: APR 2.0 proposals
Date Fri, 23 Nov 2007 16:55:14 GMT
Joe Orton wrote:
> On Fri, Nov 23, 2007 at 10:22:43AM -0600, William Rowe wrote:
>> DBM/DBD are on the right-track.  But not yet on unix.  I hope to have the
>> working "dynamic" build of these db providers working on unix by end of mo,
>> because it's critical to one of my own projects.
> 
> Can you explain what is not "on the right track" about the existing DBD 
> DSO work?

I'll do you one better, I'll illustrate in patches over the next week the
issues that remain (and fix em).

>> If LDAP/expat/ssl can be similarly refactored, and only dynaload once the
>> specific apr object is initialized,
> 
> Can you be more specific about what you are proposing here?  Only 
> "dynaload" what exactly?  The actual LDAP/expat/ssl library?

Linkages;

   yourapp
     \-- apr-2.so.0 (
           \-- libc etc
         on apr_ssl_init/open, loads...

   apr_ssl-2.so.0
     \-- libssl.so.0.9.7
         libcrypto.so.0.9.7

So until an app invokes apr_ssl_foo(), nothing's consuming memory.

Even if it's a 1:many mapping (only one valid provider at a time) this
lightens the impact of using a subset of apr features, similar to (and
better than) the good old days of 0.9.x.

For copy-on-write fork() semantics and performance, it does become important
to start consuming the various providers (with an apr_xxx_init call or whatever)
prior to fork().

Bill


Mime
View raw message