httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: Shared memory in APR. (fwd)
Date Wed, 14 Jul 1999 11:22:11 GMT
> 	So why have memory handling features in
> apr at all?

Because the alternatives are expensive.  malloc/free are not cheap
functions to use.  By providing a pool, I save time when I have to
allocate an apr type.  You don't want pools, fine replace them.  It isn't
hard.  There are a finite set of functions that implement the pools in
apr.  Granted, right now they are hidden in a few files, but really there
are just a few of them.  With a few well placed ifdefs, ap_palloc becomes
malloc.  It's really not that hard.

BTW, APR doesn't offically even expose pools to the user.  I expose
contexts, which have pools in them.  I happen to use the same function
names, but that is for ease of transition between apache-1.3.X and
apache-2.0 with apr.

The point is, apr is a "portable library", not a "portability library".
There is a very fine but important difference between the two.  Yes, apr
has a portability library as a part of it, because it is necesary.
EVERYTHING in apr will be replaceable in the future, it's just that right
now, I m only one person, and I am the only person really contributing new
code to apr, so I have done a base level that is a great deal of Apache
centric code.  Expect that to change in time, but the API will always be
consitent regardless of what the back end is doing, and the differences
will be compile time options.

Ryan

> 
> 	Maybe I have missed something here. APR isnt
> a "cross platform compatibility library" its a "cross
> platform compatibility library plus some neat apache
> features" ...
> 
> 	If the latter is the case, then I give up.
> The point of where I was going is lost. Ryan is
> correct when he said you cant just replace apr.
> Of course you cant, not when that library contains
> apache specific code that apache depends upon.
> 
> 	 My appologies for wasting your time.
> 
> Cheers Mik Voase.
> 
> -- 
> ----------------------------------------------------------------------------
>  /~\     /~\            CASTLE INDUSTRIES PTY. LTD.
>  | |_____| |            Incorporated 1969. in N.S.W., Australia
>  |         |            Phone +612 6567 1227 Fax +612 6567 1449
>  |   /~\   |            Web http://www.midcoast.com.au/~mvoase
>  |   [ ]   |            Michael H. Voase.  Director.
> ~~~~~~~~~~~~~~          Castle Industries - Industrial Strength
> Solutions.
> ----------------------------------------------------------------------------
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message