[Pkg-db-devel] Bug#247739: libdb4.2: DB_ENV->set_alloc enhancement suggestion
Tyler 'Crackerjack' MacDonald
Tyler 'Crackerjack' MacDonald <tyler@yi.org>, 247739@bugs.debian.org
Thu, 06 May 2004 11:57:11 -0700
Package: libdb4.2
Version: 4.2.52-16
Severity: wishlist
Hi,
I have only been programming using the Berekely DB library's C API for 5
months now. I find it to be an extremely strong, tight, full-featured
database engine.
The application I am currently developing is using APR (Apache2's
Portability Runtime library) for shared memory and user memory alloction
pools.
APR's pools must be specified for every allocation of memory; apr_palloc()
and apr_pcalloc() behave like alloc() and calloc(), except they require a
reference to an "apr_pool_t" to be passed as well.
Currently, if I want to use APR pools with DB4, I must allocate them first,
then specify in my database thangs that I'm using fixed-width user memory
(DB_DBT_USERMEM).
If DB4.2 had a special case for APR (or similar libraries where another
reference must be passed to malloc()), I think it would greatly increase the
flexibility of both libraries. APR's pools eliminate a lot of the headache
of memory allocation and I could see other applications being written with
greater ease if APR and DB4.2 could communicate with eachother.
All that's needed is a new function like
int
DB_ENV->set_ref_alloc(DB_ENV *db,
void *(*app_malloc)(void*, size_t),
void *(*app_realloc)(void*, void *, size_t),
void (*app_free)(void*, void *));
Then some way to specify the current pool inside a DBT or other objects
that BDB is capible of allocating memory for. Perhaps a
int DB_ENV->set_ref_alloc_ref(DB_ENV *db, void *ref);
function to specify the default pool in an environment (and then the same
for a DB, etc... ideally though, a DBT would be able to specify what pool it
wishes to use on it's own as well)
APR doesn't use "realloc" or "free", but a wrapper could be written for
"realloc" easily enough, and "free" could just be a dummy function since the
pool system will take care of that.
Do you think this is a good idea for Berekely DB?
Thanks,
Tyler
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.0-crackerjack
Locale: LANG=C, LC_CTYPE=C
Versions of packages libdb4.2 depends on:
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
-- no debconf information