Re: svn commit: r1659013 - /subversion/trunk/subversion/libsvn_subr/dso.c

On 12.02.2015 14:17, Philip Martin wrote:
> Ivan Zhakov <ivan_at_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
Received on 2015-02-12 14:50:54 CET