httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject RE: APR builds concept broken horribly
Date Mon, 05 Jun 2000 18:54:12 GMT

> > If the second, the same is done on Unix, so
> > the executable doesn't get too large, but we end up having to dynamically
> > link to things it doesn't need, which slows things down a bit.
> 
>     Are you still advocating enabling Pthreads in APR? That slows
>     down things more than a bit, if Pthreads are not needed.

APR only includes pthreads if it is found/asked for.  This is two separate
issues.  One is building APR, the other is building APR with
Apache.  Either way, APR should be configured the same.  APR has
everything possible turned on, unless it is specifically told to turn
something off.  If you are building a prefork Apache, then you should be
manually telling APR to build without threads.  But that is not this
discussion.  :-)

> > The solution I would advocate would be to build each individual part of
> > APR as a small library, and to build the huge monolithic library.  Then,
> > htpasswd just links against the small static libraries that it needs, and
> > Apache uses the big one either shared or static (I have no opinion about
> > that today).
> 
>     If APR is a collection of independent APIs, then the
>     mini-library approach works. But if any of these libraries
>     depend on another one, we would need to introduce further
>     dependencies between the mini-libraries.
> 
>     On the other side, the huge-library approach might waste some
>     time on program startup. But that is probably negligible.

For the most part, APR is a collection of independant API's.  There are a
few that are required, like pools and time.  But more of them are not
dependant on each other.  Basically:
 
(everything is dependant on libs because it provides pools so I am leaving
that out.)

       dependancy:   file_io    time          
package
file_io                           x       
threadroc               x
locks                   x
misc                    x  (for other child could be made its own library.)

Those are all of the dependancies I can think of off the top of my head.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Mime
View raw message