httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apache-2.0/src/lib/apr/include apr.hw
Date Thu, 02 Nov 2000 19:44:41 GMT
On Thu, Nov 02, 2000 at 02:22:55PM -0500, Jeff Trawick wrote:
>...
> I'm not so sure about the "inferior" and "suck" terminology here :)
> 
> If APR is a huge pig and/or large numbers of apps use the same
> version, then it is worth figuring out a way for multiple apps to use
> the same copy, even if they have different demands on it (e.g.,
> thread-safety, building in all features).
> 
> If not, it helps keeps things simple if the APR app is expected to
> statically link with a compatible version and build of APR.
> 
> For the near future (next 12 months or so?) I would guess that APR
> interfaces will change often enough that there won't be any two apps
> (or versions thereof) which need the same level of APR.  This stuff
> doesn't have the interface stability of libc, and there aren't many
> apps using it yet.
> 
> Are we really ready to offer binary compatibility across a wide-enough
> set of APR versions to expect that any two APR apps will be happy with
> the same shared version of APR?  I don't think so.

Binary compatibility is a totally different problem. That is why we have
libapr.so.1 vs libapr.so.2.

I'm talking about a particular release of APR. Let's just say APR 1.0.
Telling people that it is impossible to use as a shared library [because of
how it was designed] is very wrong.

"Here's a library. Oh, but it doesn't work except as a static library."


There are two reasons to deal with this, as I outlined before, but I'll
clarify here:

1) shared library to improve system resource usage
2) shared library because multiple pieces of a program refer to it

We all know about (1). It is (2) which is also important. Subversion uses
APR and a part of it (mod_dav_svn) will be loaded into the Apache
executable. Binding both to a shared library makes this work. Consider what
has happened with Expat: Perl's XML::Parser::Expat gets loaded into the
Apache process and barfs because Apache and the Perl module both supply
Expat names to the process. The solution for this was to move to having both
pieces refer to a shared library.

So, let's presume that a shared library version of APR is sitting on
somebody's system. It has been configured to include all of APR's features,
and a number of apps/libraries use that. How do we make it work?

We certainly can't have apr_open() have two possible semantics. Threading,
DSO support, shmem, and other-child must be enabled if available for the
platform (these are the four configurable options in APR).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message