On 31 Mar 2001, Jeff Trawick wrote:
> "Bill Stoddard" <[EMAIL PROTECTED]> writes:
>
> > Anyone want to step up to creating a good set of memory allocation
> > routines that allow putting elements back on a free list?
>
> Greg Ames will do it (I mean Greg and/or I will do it :) ). We were
> chatting before he left for the high seas about the seeming inability
> to subcontract this work out to anybody else.
Okay, you guilted me into it... I've been meaning to do this for months
and just hadn't gotten around to it. I started work on it today... should
have _something_ for you all to look at within a day or so. I'm basically
just adapting what you all (Bill, Jeff, Greg) already wrote by splitting
Bill's apr_malloc out into a stack interface (implementable in a lock-free
manner in ways such as those used by the jstack.h that Jeff and Greg
wrote) and a leaner apr_malloc interface on top of that. If all else
fails and there's no lock-free stack implemented on a given architecture,
then we fall back to a locking stack. apr_malloc() doesn't care whether
the stack is locking or not... it just uses whichever one is available to
it.
(Possible meta-issue, probably more suited to discussion on the APR list:
apr/include has an 'arch' subdirectory, but it's misnamed... it should be
apr/include/os and not apr/include/arch. apr/include/arch would contain
subdirs like i386, sparc, etc, if the need for that existed. We don't
need a real 'arch' directory for anything currently in APR, but these lock
free lists could potentially change that...)
--Cliff
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
