You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Evgeny Kotkov <ev...@visualsvn.com> on 2015/02/12 13:26:57 UTC
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Philip Martin <ph...@apache.org> writes:
> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
> fixes a crash in the DSO hash code when running the C tests in
> parallel.
>
> * subversion/libsvn_subr/dso.c
> (atomic_init_func): New.
> (svn_dso_load): Use svn_atomic__init_once.
I think we should also address this problem in our test suite. As I see, this
change avoids segfaults with --enable-runtime-module-search, but there is more
to it. Documentation for svn_dso_initialize2() states the following (by the
way, the "will not be entirely thread safe" part is now outdated, right?):
* @note This should be called prior to the creation of any pool that
* is passed to a function that comes from a DSO, otherwise you
* risk having the DSO unloaded before all pool cleanup callbacks
* that live in the DSO have been executed. If it is not called
* prior to @c svn_dso_load being used for the first time there
* will be a best effort attempt made to initialize the subsystem,
* but it will not be entirely thread safe and it risks running
* into the previously mentioned problems with DSO unloading and
* pool cleanup callbacks.
I am not sure that taking some risks within the test suite is a good idea,
and I think that we should call functions like svn_dso_initialize2() and
svn_fs_initialize(). If we don't, everything might still work fine, but it
also might not, and we could spend a lot of time debugging random failures
if a test runs into one of these pitfalls happening due to the absense of
explicit initialization. We do call these initializers in mod_dav_svn, svn,
svnserve — so why not also do the same in the test programs?
I don't see a reason to use a custom way of bootstrapping things within
svn_test_main(), as opposed to main() functions in svn, svnadmin and other
command-line tools, and I attached a patch that brings this common approach
to svn_test_main(). Quick inspection shows a couple of other programs that
should probably do the same, e.g., atomic-ra-revprop-change. However, I
think this is less important, and that we could do it separately.
What do you think?
Regards,
Evgeny Kotkov
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 13 February 2015 at 18:54, Philip Martin <ph...@codematters.co.uk> wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
>> Ivan Zhakov <iv...@visualsvn.com> writes:
>>
>>> This API is present from Subversion 1.2, so I suggest add call to
>>> svn_dso_initialize2() in svn_ra_initialize()/svn_fs_inialize(): do you
>>> have any objections against this approach?
>>
>> Yes, that sounds like a good idea.
>
> No objections. And, yes, that sounds like a good idea.
>
Done in r1659604.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> Ivan Zhakov <iv...@visualsvn.com> writes:
>
>> This API is present from Subversion 1.2, so I suggest add call to
>> svn_dso_initialize2() in svn_ra_initialize()/svn_fs_inialize(): do you
>> have any objections against this approach?
>
> Yes, that sounds like a good idea.
No objections. And, yes, that sounds like a good idea.
--
Philip
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Philip Martin <ph...@wandisco.com>.
Ivan Zhakov <iv...@visualsvn.com> writes:
> This API is present from Subversion 1.2, so I suggest add call to
> svn_dso_initialize2() in svn_ra_initialize()/svn_fs_inialize(): do you
> have any objections against this approach?
Yes, that sounds like a good idea.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 12 February 2015 at 21:28, Philip Martin <ph...@wandisco.com> wrote:
> Ivan Zhakov <iv...@visualsvn.com> writes:
>
>> As far I understand out testsuite still may fail in some rare
>> circumstances with --parallel option, until we add
>> svn_dso_initialize2(). It's bad when tests are failing sometimes.
>
> I just seen a failure and it revealed the current bug. I think the
> tests explicitly clear the pools passed to RA/FS so they already follow
> the rules and will not have a problem. A test would have to fail to
> clear a pool for there to be a problem, and that would most likely be a
> bug that should be fixed.
>
>> We already documented that applications *should* call
>> svn_dso_initialize2() on startup. Why test some unrecommended usage of
>> our API that I known to lead problems?
>
> svn_dso_initialize2 didn't exist until 1.6 and is only documented in
> svn_dso.h. Do we expect people writing applications using the high
> level API to read that? Do we expect people using old applications to
> update them? Is it possible to call svn_dso_initialize2 when using the
> bindings?
>
svn_dso_initialize2() is just extended version of svn_dso_initialize()
which exists since 1.4. The svn_dso_load() also introduced in 1.4.
>> Do we want to fight problems
>> like we had with ra-test in future?
>
> I haven't followed the details but I think the ra-test problem was
> caused by failure to close a tunnel, nothing to do with initialization.
>
Probably, but we suspected BDB initialization problems and spend some
time to check it.
>> Testing on-the-fly
>> initialization() is a good goal, but not as expense of usual
>> development IMO. We may add special 'on-the-fly-initialization' test
>> program if you think that it's important to test this behavior. Just
>> my $0.02
>
> I'm still not seeing a gain, only the need to write another test.
>
The gain is to avoid unexpected behavior in our test suite. It's also
could be a problem if some application developer will use our test
application as starting point for his app.
Please understand me correctly: I'm not against improving
svn_dso_initialize2()/svn_dso_load() and I voted for r1659315 fix in
1.8.x. I'm just trying to demonstrate that there are still possible
circumstances for problems and do not why we should write our test
application in the not recommended way.
Btw svn_dso_load() is used for RA and FS modules. We already have
svn_ra_initialize() and svn_fs_initialize() with docstring that these
functions *must be* called before using any RA functions:
[[[
/**
* Initialize the RA library. This function must be called before using
* any function in this header, except the deprecated APIs based on
*/
]]]
This API is present from Subversion 1.2, so I suggest add call to
svn_dso_initialize2() in svn_ra_initialize()/svn_fs_inialize(): do you
have any objections against this approach?
--
Ivan Zhakov
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Philip Martin <ph...@wandisco.com>.
Ivan Zhakov <iv...@visualsvn.com> writes:
> As far I understand out testsuite still may fail in some rare
> circumstances with --parallel option, until we add
> svn_dso_initialize2(). It's bad when tests are failing sometimes.
I just seen a failure and it revealed the current bug. I think the
tests explicitly clear the pools passed to RA/FS so they already follow
the rules and will not have a problem. A test would have to fail to
clear a pool for there to be a problem, and that would most likely be a
bug that should be fixed.
> We already documented that applications *should* call
> svn_dso_initialize2() on startup. Why test some unrecommended usage of
> our API that I known to lead problems?
svn_dso_initialize2 didn't exist until 1.6 and is only documented in
svn_dso.h. Do we expect people writing applications using the high
level API to read that? Do we expect people using old applications to
update them? Is it possible to call svn_dso_initialize2 when using the
bindings?
> Do we want to fight problems
> like we had with ra-test in future?
I haven't followed the details but I think the ra-test problem was
caused by failure to close a tunnel, nothing to do with initialization.
> Testing on-the-fly
> initialization() is a good goal, but not as expense of usual
> development IMO. We may add special 'on-the-fly-initialization' test
> program if you think that it's important to test this behavior. Just
> my $0.02
I'm still not seeing a gain, only the need to write another test.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 12 February 2015 at 20:51, Philip Martin <ph...@wandisco.com> wrote:
> Ivan Zhakov <iv...@visualsvn.com> writes:
>
>> 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?
>
> What do we gain? We already have programs that that call
> svn_dso_initialize2: svn, svnserve, ... If we make all our test
> programs do the same we lose the ability to test our on-the-fly
> initialization, the very thing that revealed the current problem.
>
As far I understand out testsuite still may fail in some rare
circumstances with --parallel option, until we add
svn_dso_initialize2(). It's bad when tests are failing sometimes.
We already documented that applications *should* call
svn_dso_initialize2() on startup. Why test some unrecommended usage of
our API that I known to lead problems? Do we want to fight problems
like we had with ra-test in future? Testing on-the-fly
initialization() is a good goal, but not as expense of usual
development IMO. We may add special 'on-the-fly-initialization' test
program if you think that it's important to test this behavior. Just
my $0.02
--
Ivan Zhakov
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Philip Martin <ph...@wandisco.com>.
Ivan Zhakov <iv...@visualsvn.com> writes:
> 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?
What do we gain? We already have programs that that call
svn_dso_initialize2: svn, svnserve, ... If we make all our test
programs do the same we lose the ability to test our on-the-fly
initialization, the very thing that revealed the current problem.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 12 February 2015 at 20:27, Philip Martin <ph...@wandisco.com> wrote:
> Ivan Zhakov <iv...@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
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Philip Martin <ph...@wandisco.com>.
Ivan Zhakov <iv...@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.
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.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 12 February 2015 at 16:48, Branko Čibej <br...@wandisco.com> wrote:
> On 12.02.2015 14:17, Philip Martin wrote:
>> Ivan Zhakov <iv...@visualsvn.com> writes:
>>
>>> Multi-threaded application that didn't call svn_dso_initialize2()
>>> before creating any other pools will fail anyway under some
>>> circumstances. The problem with cleanup handles, not with concurrent
>>> initialization.
>> Perhaps we could fix the problem (for recent APR) by using an unmanged
>> pool. I'm not sure how we would arrange for such a pool to be cleaned
>> up, would an atexit handler work? Or perhaps we just accept the leak?
>
> A planned leak at process exit isn't really a leak. DSOs should never be
> unloaded anyway, there are too many intertwined dependencies to try to
> unravel them all.
>
Currently, svn_dso_load() loads all modules in DSO_POOL which is
created in svn_dso_initialize2(). DSO modules will be unloaded once
DSO_POOL is destroyed: the apr_dso_load() requires POOL argument to
load DSO module.
Than imagine the following pretty valid use case:
1. Application creates some root pool (POOL1)
2. Calls svn_fs_open("repos", POOL1)
2.1 svn_fs_open() implementation calls svn_dso_load() to load DSO
module with FS-library implementation.
2.2. svn_dso_load() calls svn_dso_intialize2() since it is not
intialized yet
2.3 svn_dso_initialize2 creates second root pool (DSO_POOL) and
uses this pool to load DSO module
3. Application uses FS
4. Application exits, without destroying it's root pool (POOL1).
Instead it calls apr_terminate() which destroy root pools in reverse
order:
4.1. DSO_POOL destroyed and all DSO modules are unloaded.
** At this point the code with FS-implementation is unloaded
from address space **
4.2. Then POOL1 is destroyed and some cleanup handlers registered
by FS-library is called: BOOM -- the code is already unloaded at 4.1
(in the multi-threaded application situation become worse, but harder
to reproduce. Heisenbugs guaranteed)
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().
--
Ivan Zhakov
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Branko Čibej <br...@wandisco.com>.
On 12.02.2015 14:17, Philip Martin wrote:
> Ivan Zhakov <iv...@visualsvn.com> writes:
>
>> Multi-threaded application that didn't call svn_dso_initialize2()
>> before creating any other pools will fail anyway under some
>> circumstances. The problem with cleanup handles, not with concurrent
>> initialization.
> Perhaps we could fix the problem (for recent APR) by using an unmanged
> pool. I'm not sure how we would arrange for such a pool to be cleaned
> up, would an atexit handler work? Or perhaps we just accept the leak?
A planned leak at process exit isn't really a leak. DSOs should never be
unloaded anyway, there are too many intertwined dependencies to try to
unravel them all.
-- Brane
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Philip Martin <ph...@wandisco.com>.
Ivan Zhakov <iv...@visualsvn.com> writes:
> Multi-threaded application that didn't call svn_dso_initialize2()
> before creating any other pools will fail anyway under some
> circumstances. The problem with cleanup handles, not with concurrent
> initialization.
Perhaps we could fix the problem (for recent APR) by using an unmanged
pool. I'm not sure how we would arrange for such a pool to be cleaned
up, would an atexit handler work? Or perhaps we just accept the leak?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 12 February 2015 at 15:42, Branko Čibej <br...@wandisco.com> wrote:
> On 12.02.2015 13:26, Evgeny Kotkov wrote:
>> Philip Martin <ph...@apache.org> writes:
>>
>>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>>> fixes a crash in the DSO hash code when running the C tests in
>>> parallel.
>>>
>>> * subversion/libsvn_subr/dso.c
>>> (atomic_init_func): New.
>>> (svn_dso_load): Use svn_atomic__init_once.
>> I think we should also address this problem in our test suite. As I see, this
>> change avoids segfaults with --enable-runtime-module-search, but there is more
>> to it. Documentation for svn_dso_initialize2() states the following (by the
>> way, the "will not be entirely thread safe" part is now outdated, right?):
>>
>> * @note This should be called prior to the creation of any pool that
>> * is passed to a function that comes from a DSO, otherwise you
>> * risk having the DSO unloaded before all pool cleanup callbacks
>> * that live in the DSO have been executed. If it is not called
>> * prior to @c svn_dso_load being used for the first time there
>> * will be a best effort attempt made to initialize the subsystem,
>> * but it will not be entirely thread safe and it risks running
>> * into the previously mentioned problems with DSO unloading and
>> * pool cleanup callbacks.
>>
>> I am not sure that taking some risks within the test suite is a good idea,
>> and I think that we should call functions like svn_dso_initialize2() and
>> svn_fs_initialize(). If we don't, everything might still work fine, but it
>> also might not, and we could spend a lot of time debugging random failures
>> if a test runs into one of these pitfalls happening due to the absense of
>> explicit initialization. We do call these initializers in mod_dav_svn, svn,
>> svnserve — so why not also do the same in the test programs?
>>
>> I don't see a reason to use a custom way of bootstrapping things within
>> svn_test_main(), as opposed to main() functions in svn, svnadmin and other
>> command-line tools, and I attached a patch that brings this common approach
>> to svn_test_main(). Quick inspection shows a couple of other programs that
>> should probably do the same, e.g., atomic-ra-revprop-change. However, I
>> think this is less important, and that we could do it separately.
>>
>> What do you think?
>
>
> We should make our implementation work without having to run the
> initializer functions. This is a lot easier for API users. There's
> almost nothing we can't do within an svn_atomic__init_once block. The
> only problematic feature is creating pools in an unknown thread context,
> because we won't know the pool destruction order. Even this problem has
> been mostly solved in the BDB DB_REGISTER support code.
>
We should, but sometimes we cannot. As far I understand documentation
for svn_dso_initialize2() is exactly that case:
[[[
* @note This should be called prior to the creation of any pool that
* is passed to a function that comes from a DSO, otherwise you
* risk having the DSO unloaded before all pool cleanup callbacks
* that live in the DSO have been executed. If it is not called
* prior to @c svn_dso_load being used for the first time there
* will be a best effort attempt made to initialize the subsystem,
* but it will not be entirely thread safe and it risks running
* into the previously mentioned problems with DSO unloading and
* pool cleanup callbacks.
]]]
Multi-threaded application that didn't call svn_dso_initialize2()
before creating any other pools will fail anyway under some
circumstances. The problem with cleanup handles, not with concurrent
initialization.
--
Ivan Zhakov
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 12.02.2015 13:26, Evgeny Kotkov wrote:
>> Philip Martin <ph...@apache.org> writes:
>>
>>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>>> fixes a crash in the DSO hash code when running the C tests in
>>> parallel.
>>>
>>> * subversion/libsvn_subr/dso.c
>>> (atomic_init_func): New.
>>> (svn_dso_load): Use svn_atomic__init_once.
>> I think we should also address this problem in our test suite. As I see, this
>> change avoids segfaults with --enable-runtime-module-search, but there is more
>> to it. Documentation for svn_dso_initialize2() states the following (by the
>> way, the "will not be entirely thread safe" part is now outdated, right?):
>>
>> * @note This should be called prior to the creation of any pool that
>> * is passed to a function that comes from a DSO, otherwise you
>> * risk having the DSO unloaded before all pool cleanup callbacks
>> * that live in the DSO have been executed. If it is not called
>> * prior to @c svn_dso_load being used for the first time there
>> * will be a best effort attempt made to initialize the subsystem,
>> * but it will not be entirely thread safe and it risks running
>> * into the previously mentioned problems with DSO unloading and
>> * pool cleanup callbacks.
>>
>> I am not sure that taking some risks within the test suite is a good idea,
>> and I think that we should call functions like svn_dso_initialize2() and
>> svn_fs_initialize(). If we don't, everything might still work fine, but it
>> also might not, and we could spend a lot of time debugging random failures
>> if a test runs into one of these pitfalls happening due to the absense of
>> explicit initialization. We do call these initializers in mod_dav_svn, svn,
>> svnserve — so why not also do the same in the test programs?
>>
>> I don't see a reason to use a custom way of bootstrapping things within
>> svn_test_main(), as opposed to main() functions in svn, svnadmin and other
>> command-line tools, and I attached a patch that brings this common approach
>> to svn_test_main(). Quick inspection shows a couple of other programs that
>> should probably do the same, e.g., atomic-ra-revprop-change. However, I
>> think this is less important, and that we could do it separately.
>>
>> What do you think?
>
>
> We should make our implementation work without having to run the
> initializer functions. This is a lot easier for API users. There's
> almost nothing we can't do within an svn_atomic__init_once block. The
> only problematic feature is creating pools in an unknown thread context,
> because we won't know the pool destruction order. Even this problem has
> been mostly solved in the BDB DB_REGISTER support code.
It also means that we will be doing no testing at all of our on-the-fly
initialisation. These functions were all introduced after 1.0 and in
the early days it was legitimate to use Subversion without making these
initialisation calls. The reason we have on-the-fly initialisation is
that we want to remain compatible with old code. Some of these tests
date from before the initialisation functions were introduced, they are
examples of code that is supposed to keep working.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c
Posted by Branko Čibej <br...@wandisco.com>.
On 12.02.2015 13:26, Evgeny Kotkov wrote:
> Philip Martin <ph...@apache.org> writes:
>
>> Wrap svn_dso_initialize2 call with svn_atomic__init_once, this
>> fixes a crash in the DSO hash code when running the C tests in
>> parallel.
>>
>> * subversion/libsvn_subr/dso.c
>> (atomic_init_func): New.
>> (svn_dso_load): Use svn_atomic__init_once.
> I think we should also address this problem in our test suite. As I see, this
> change avoids segfaults with --enable-runtime-module-search, but there is more
> to it. Documentation for svn_dso_initialize2() states the following (by the
> way, the "will not be entirely thread safe" part is now outdated, right?):
>
> * @note This should be called prior to the creation of any pool that
> * is passed to a function that comes from a DSO, otherwise you
> * risk having the DSO unloaded before all pool cleanup callbacks
> * that live in the DSO have been executed. If it is not called
> * prior to @c svn_dso_load being used for the first time there
> * will be a best effort attempt made to initialize the subsystem,
> * but it will not be entirely thread safe and it risks running
> * into the previously mentioned problems with DSO unloading and
> * pool cleanup callbacks.
>
> I am not sure that taking some risks within the test suite is a good idea,
> and I think that we should call functions like svn_dso_initialize2() and
> svn_fs_initialize(). If we don't, everything might still work fine, but it
> also might not, and we could spend a lot of time debugging random failures
> if a test runs into one of these pitfalls happening due to the absense of
> explicit initialization. We do call these initializers in mod_dav_svn, svn,
> svnserve — so why not also do the same in the test programs?
>
> I don't see a reason to use a custom way of bootstrapping things within
> svn_test_main(), as opposed to main() functions in svn, svnadmin and other
> command-line tools, and I attached a patch that brings this common approach
> to svn_test_main(). Quick inspection shows a couple of other programs that
> should probably do the same, e.g., atomic-ra-revprop-change. However, I
> think this is less important, and that we could do it separately.
>
> What do you think?
We should make our implementation work without having to run the
initializer functions. This is a lot easier for API users. There's
almost nothing we can't do within an svn_atomic__init_once block. The
only problematic feature is creating pools in an unknown thread context,
because we won't know the pool destruction order. Even this problem has
been mostly solved in the BDB DB_REGISTER support code.
-- Brane