httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <ras...@lerdorf.on.ca>
Subject Re: Shared memory in APR. (fwd)
Date Wed, 14 Jul 1999 05:37:49 GMT
> IF APR stuck to its original charter then this would not
> be an issue. APR has sucked in features of apache that
> IMHO dont belong there ( since when have you seen an OS
> expose a pool based memory system in its api? )
> APR ceased being a general purpose run time library
> when specific implementations for structures and
> methods were bundled in. That is why it will fail
> as a general purpose cp layer. In some applications
> it may not be appropriate to use a pool based memory
> system. Pools are an applied method of handling
> memory ( in fact, someone may come up with something
> _better_ than pools in future, however apr will be
> stuck with pools in its curent incarnation. Very
> inflexible ). If it were to just expose the OS api,
> ( calloc, alloc, free and friends ) , then it would
> be usefull to other applications. Once the OS api
> is exposed as a uniform api then build your pools
> and tables on _top_ of the run time library api,
> not as part of it.

I guess I am missing something here.  What would be the point of APR
wrapping something like malloc() and free() directly?  These functions do
the same everywhere, do they not?

-Rasmus


Mime
View raw message