[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r33014 - trunk/subversion/libsvn_subr

From: Ivan Zhakov <zhakov_at_tigris.org>
Date: Wed, 17 Sep 2008 17:18:58 +0400

On Thu, Sep 11, 2008 at 2:28 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: zhakov_at_tigris.org [mailto:zhakov_at_tigris.org]
>> Sent: woensdag 10 september 2008 19:24
>> To: svn_at_subversion.tigris.org
>> Subject: svn commit: r33014 - trunk/subversion/libsvn_subr
>>
>> Author: zhakov
>> Date: Wed Sep 10 10:24:19 2008
>> New Revision: 33014
>>
>> Log:
>> Load crypt32.dll library once in authentication provider
>> initialization,
>> instead of every time in callback.
>> Loading/unloading library every time causes random deadlocks in
>> FreeLibrary().
>>
>> * subversion/libsvn_subr/ssl_server_trust_providers.c
>> (svn_auth_get_windows_ssl_server_trust_provider): Load crypt32.dll
>> and
>> resolve symbols here. Library will be unloaded on pool clearing.
>> (windows_ssl_server_trust_first_credentials): Use functions pointers
>> from baton.
>> (windows_ssl_server_trust_cleanup): New function for unloading
>> crypt32.dll
>
> Hi,
>
> subversion/libsvn_subr/win32_crypto.c's get_crypto_function() and its callers might have
> the same problem as they load and free the same dll.
>
> If the library unloading is the issue, we should probably move all this code to a one time
> atomic initialization to make the library safe for multithreaded users.
>
> I see no problem in loading the library once when first needed and keeping it in memory
> after that (The same behavior as hard linking to the library).
Good suggestion,
Done in r33128.

-- 
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-17 15:19:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.