[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