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
