Commit graph

5 commits

Author SHA1 Message Date
asau
e1ab7079b6 Drop superfluous PKG_DESTDIR_SUPPORT, "user-destdir" is default these days. 2012-10-31 11:16:30 +00:00
wiz
e2f84ad43f Reset maintainer for retired developers. 2011-02-28 14:52:37 +00:00
joerg
bacea7cad5 Remove @dirrm entries from PLISTs 2009-06-14 17:48:39 +00:00
bjs
d11147ba05 Update to 20080221 snapshot, primarily because I forgot to put
a copy of this in LOCAL_PORTS.  While here, add BUILDLINK_LDADD/LDFLAGS
for convenience (LDFLAGS is set with =?).
2008-02-22 08:12:58 +00:00
bjs
3555c5e26f Import libarena, a BSD-licensed memory allocator abstraction API.
Also included are four allocators which also serve as examples
as to how to use the interface.  AFAIK, it's sort of like vmem(9)
in userland (not that I know much about vmem, for the manpage
is quite terse, heh).

I imported this not as a dependency, but because I thought it
looked interesting, especially with regard to what's outlined
in the last paragraph.  I may use it in porting some linux audio
software at some point, though that's still a ways off ...

A short blurb:


Libarena is a custom memory allocator interface and implementation. Four
allocators are provided: flat LIFO arena allocator, object pool allocator
and two malloc(3) wrappers: one which returns the pointers unadulterated
and one which obeys the requested, arbitrary alignment. These can be used
directly, or through their exported prototype interfaces.

Libarena is meant to provide a baseline interface so allocator's can be
stacked, and to provide a simple and well defined interface for libraries
and applications without becoming mired in features or capabilities. It is
not meant to restrict or confine what custom allocators can actually
accomplish. For instance, the included pool and arena allocators include a
suite of string utilities which aren't available in the generic exportable
interface. Note that these string utilities are built upon a generic
interface (see util.h) which can take the prototypical allocation context,
so they are also available to any 3rd party compatible allocators.

Surprisingly few malloc(3) library "replacements" or plug-in interfaces
support a context pointer argument. They're useless for many or most of
the tasks where the ability to specify an alternate malloc(3) could
actually be useful, e.g. poor man's RAII. For network daemons especially
this feature is useful; all allocations for a particular session can be
freed simply by closing the lowest-level allocator object.
2008-02-12 02:40:37 +00:00