On 12 February 2015 at 20:27, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Ivan Zhakov <ivan_at_visualsvn.com> writes:
>
>> Please understand my correctly: I'll be glad see Subversion doesn't
>> require single-thread initialize functions, but I don't see how is it
>> possible in reliable way. Currently the only reliable solution is to
>> call svn_dso_initialize2() as first call after apr_initialize().
>
> That may not be reliable if an unmanged pool is passed to the FS layer.
>
> In the end there are rules for using pools with Subversion. One rule is
> that pools passed to the RA/FS layers need to be cleared before the DSO
> is unloaded. Calling svn_dso_initialize2 early is a way to do that in
> lots of cases. Explicitly clearing all pools passed to RA/FS also
> works.
>
Sorry, but I've lost what problem we're trying to solve now? Why just
do not add call to svn_dso_initialize2() (or svn_cmdline_init()) in
our testsuite and move forward?
> To claim that calling svn_dso_initialize2 as the first call after
> apr_initialize is the only solution is impractical: mod_dav_svn is never
> going to be able to do that.
>
The mod_dav_svn puts init_dso() registers callback with highest
priority and has comment explaining the problem:
subversion\mod_dav_svn\mod_dav_svn.c:147
[[[
/* This isn't ideal, we're not actually being called before any
pool is created, but we are being called before the server or
request pools are created, which is probably good enough for
98% of cases. */
]]]
--
Ivan Zhakov
Received on 2015-02-12 18:39:46 CET