httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: apache-2.0/src/lib/apr/include apr.hw
Date Thu, 02 Nov 2000 18:48:01 GMT
On Thu, Nov 02, 2000 at 11:28:22AM -0800, wrote:
> Neither.   Apache uses a statically compiled version of APR.  If
> Subversion was smart, it would too.  This is a standard problem with
> shared libraries, and that is one of the reasons that Apache is statically
> linking APR.  We have never figured out the "correct" way to deal with
> shared libraries with APR.  Think of it this way.
> I have two APR programs, one is threaded, one isn't.   If I compile APR to
> have threads, then I hurt the performance in the non-threaded program.  If
> I compile APR non-threaded, then I break the threaded one.
> The only sane solution with a library with as many options as APR has is
> to compile most programs static.

That is a total cop-out for an inferior design.

I have never heard of a library that says "sorry, you *must* statically link
with me [because I suck otherwise]".

People statically link executables to simplify installation and problems
with version skew. But they don't do it because the library forces them to.

The threading stuff you mention is also bogus. APR can be compiled with
threads and be nearly as efficient as without them. All it takes is a simple
global flag to indicate whether the particular app is using APR in a
threaded manner (although, personally, I'd rather see it as a flag in the
context/pool since you could have an app and a third-party library [linked
together] both using APR (e.g. Apache and Subversion) and each wanting to
use it in different ways; global flags are dangerious in that scenario). In
any case, once you have a flag, those places where we need a mutex become a
simple flag test, followed by the mutex lock/unlock. (and the test/operation
can easily occur under a macro's covers).


Greg Stein,

View raw message