On 8/3/06, Garrett Rooney <firstname.lastname@example.org> wrote:
> All right, I dislike this solution, but I've run out of other ideas.
> Here's a patch that adds yet another kinda-sorta-optional
> initialization function that handles the global dso pool creation. To
> be entirely correct it must be run before any pool is created that
> will be used to allocate anything from within a DSO loaded library.
> I've included changes to svn_cmdline_init and mod_dav_svn to get this
> called at the appropriate time in each. If you don't call it then the
> DSO stuff will initialize itself on demand, but it's not certain to
> work correctly in the face of --enable-dso.
> This patch also rolls back the previous "fix" to the problem, as most
> of it is no longer needed.
> Any comments are much appreciated.
Here's an updated version of the patch that fixes a few small bugs and
updates it to work with what's in trunk now. I remain convinced that
this is the way we're going to have to go, all alternate solutions
seem to fall down under some pool creation/destruction ordering
situations and I don't think there's a 100% solution to the problem
other than making changes in APR itself.
Add an initialization function for a global DSO pool and a function to
use it when loading DSOs. Assuming the initialization function is called
sufficiently early this fixes --enable-dso, really this time.
(load_ra_module): Use the new svn_dso_load function.
* subversion/include/svn_dso.h: New file.
(load_module): Use svn_dso_load.
(svn_cmdline_init): Call svn_dso_initialize.
* subversion/libsvn_subr/dso.c: New file.
(init_dso): New function.
(register_hooks): Set up init_dso hook.
Received on Fri Aug 4 23:14:50 2006
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org