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: [PATCH] Optimized MD5 implementation from OpenSSL
Date Wed, 03 Jan 2007 20:02:59 GMT
Justin Erenkrantz wrote:
> On 1/3/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> 
>> >> Now - I thought the public discussion lists were moving twords disolving
>> >> APR-util into smaller libraries, dependent on specific features that
>> >> wouldn't swallow the entire world of unnecessary library functionality
>> >> into every runtime?
>> >
>> > That's part of the discussions that have been here on list, but
>> > frankly, I've never seen anyone say how a dynamic APR would work
>> > reliably.  In fact, I think the eventual consensus was that
>> > splitting-off approach could never work at all.
>>
> http://mail-archives.apache.org/mod_mbox/apr-dev/200608.mbox/%3C7edfeeef0608110942h8caf669t96585359a5c61f17@mail.gmail.com%3E
> 
> That's how I interpreted the outcome of that thread.

That's not how I interpreted it.  I read that it's necessary to load modules
such that...

 * global pool

   \- DSO's pool

      \- DSO's object's pools

Of course, it's possible to create the objects in the DSO's pool, because we
run the cleanups in LIFO order.  It's also possible to load it all in the global
pool.  A bigger change for 2.0 would be to ensure the global pool IS always one
threadsafe pool, which I'd strongly support.

 * global pool

 \- DSO's object's pools

 \- DSO's pool

and other pool usage layouts all lead to the crashes that Garrett described.

I'd argue this is program design error, and not

But you hint that we would dynaload (for example) the apr-ldap component, or
at least the libldap/liblber libraries.  I'm not arguing that.

I'm suggesting libaprldap-2.so would be dynalinked to the user's app.  Rather
than just plugging in APR_UTIL_LIBS, a user who wanted ldap plus dbd would use
APR_LDAP_LIBS and APR_DBD_LIBS.

Sure, we would proliferate five or more seperate aprfoo-2.so dso's.  Is that
bad?  Is that worse than dragging in MB's of code per aprfoo-2.so component,
that aren't needed?

[Snip httpd/svn-centric dialog]

The goal of 2.0 should be to make apr user's (the developer's) experience
less painful.  That means a more consistent API, a lighter weight core of
functionality that applies to them, and fewer surprises.  At least that's
my humble 2c.


Mime
View raw message