apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: Dependencies and Modularity in APR
Date Mon, 13 Dec 2004 01:15:17 GMT
On Mon, 13 Dec 2004, Graham Leggett wrote:

> Nick Kew wrote:
> > This seems to me less than ideal even for DBM.   In the case of DBD,
> > the backends are major applications in themselves, and hardwiring them
> > at build time seems to be seriously suboptimal.  So I've re-hacked
> > the DBD code to load them dynamically when APR_DSO is enabled.
> (Forgive what may be a stupid question) Am I correct in assuming that
> when the platform does not support DSO, it will be built natively into
> the library as it is now? (assuming the person compiling the code has
> not indicated otherwise at compile time)

Yep.  It's all in the revised apr_dbd.c attached to my Saturday post.
I switched drivers to a hash (static in apr_dbd.c).  An init function
apr_dbd_init sets up the hash and if necessary also a thread mutex.

After that it depends on APR_HAS_DSO.  If yes, the hash is populated
and drivers loaded on the first call to apr_dbd_get_driver() for
a name (subsequent calls just look it up in the hash).  That load
is what the thread mutex (if APR_HAS_DSO and APR_HAS_THREADS) is for.
If APR_HAS_DSO is false, all the drivers are initialised in apr_dbd_init.

It's basically analagous to mod_so in httpd.

Nick Kew

View raw message