httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Small direction change for APR's file I/O routines.
Date Tue, 11 Jan 2000 02:18:14 GMT

> > Or, I have seriously had three or four people tell me that they really
> > want to have APR provide a stat cache for them.  I really don't care, but
> > if enough people continue to ask for it, I will put it into APR.
> I'm with Dean on this one: I don't think a library can always do a great
> job of it. The application knows best about its behavior -- when/why it
> calls stat(), when it should purge, how big the cache should be, etc.

Obviously I need to do one of two things.  Either never speak about
possible future enhancements to APR, or explain them in detail whenever I
do.  :-)  This wasn't meant as a "I'm doing this tomorrow" kind of thing,
but I figure I'll quell this now since I brought it up.

I have had a couple of people express the desire for a stat cache in APR,
this does not mean APR will manage the cache, it just means APR will
provide the functions necessary to do the cache management for you.  It
doesn't even have to be limited to a stat cache, it could conceivably
cache anything.  For example, why should the base Apache, and mod_proxy,
and mod_php, and mod_perl all have cache code in them?  For the most part,
a cache is a cache what is being cached changes, how long it should be
cached for changes, but the basic operations remain the same.  Let me give
you an example of the API I was considering.

ap_initialize_cache(ap_cache_t *thecache, int num_elements, func
		*cleanup_routine, ap_context_t *cont);
ap_add_element(void *elem, ap_cache_t *thecache, int timeout);
ap_get_element(void *elem, ap_cache_t *thecache);
ap_free_cache(ap_cache_t *thecache);

This is not a set API, there isn't even ideathing saying this will ever be
implemented, but the idea of APR providing cache'ing functions is the same
as APR providing queue'ing functions.  These are portable, and it doesn't
make any sense for every program to write them again.  It would even be
possible for programs to compile APR without having these functions be

I will not be addressing the stat cache or cache'ing issue again, because
it isn't really important to Apache right now, it has nothing to do with
Apache 2.0, and I never should have brought it up.  But, providing basic
routines like this is a good thing for APR to do, IMO.  I know mod_proxy
needs a cache, and I know mod_php and mod_perl already use a cache, IMHO,
it should be the same code, and it isn't currently.

> The library just can't know all this.

And, as I just explained, the library doesn't have to know any of it.


View raw message