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

Re: svn commit: r1141868 - /subversion/branches/svn_mutex/BRANCH-README

From: Stefan Fuhrmann <eqfox_at_web.de>
Date: Mon, 04 Jul 2011 23:57:24 +0200

On 01.07.2011 16:56, Daniel Shahaf wrote:
> stefan2_at_apache.org wrote on Fri, Jul 01, 2011 at 08:34:20 -0000:
>> Author: stefan2
>> Date: Fri Jul 1 08:34:20 2011
>> New Revision: 1141868
>>
>> URL: http://svn.apache.org/viewvc?rev=1141868&view=rev
>> Log:
>> On the svn_mutex branch, add a readme as requested.
>>
>> * BRANCH-README: new file
>>
>> Added:
>> subversion/branches/svn_mutex/BRANCH-README
>>
>> Added: subversion/branches/svn_mutex/BRANCH-README
>> URL: http://svn.apache.org/viewvc/subversion/branches/svn_mutex/BRANCH-README?rev=1141868&view=auto
>> ==============================================================================
>> --- subversion/branches/svn_mutex/BRANCH-README (added)
>> +++ subversion/branches/svn_mutex/BRANCH-README Fri Jul 1 08:34:20 2011
>> @@ -0,0 +1,19 @@
>> +svn_mutex__t is supposed to be an almost zero-overhead
>> +wrapper around apr_thread_mutex_t. And if it wasn't for
>> +the 1.7 stabilization, this change would be developed
>> +directly on /trunk.
>> +
>> +The basic idea is to move code patterns like
>> +
>> +#if APR_HAS_THREADS
>> + if (my_struct->mutex)
>> + {
>> + status = apr_thread_mutex_lock(my_struct->mutex);
>> + if (status)
>> + return svn_error_wrap_apr(...)
>> + }
>> +#endif
>> +
>> +into a dedicated function such that callers may simply do
>> +
>> + SVN_ERR(svn_mutex__lock(my_struct->mutex));
> SVN_ERR(svn_mutex__with_lock(&mystruct->mutex, my_callback));
>
That would be nice but the varying parameter lists
of "my_callback" make this impractical. In particular,
there seems to be no way to safely cast foo(a,b,c)
to foo(void*, ...), i.e. using variadic parameter lists.

-- Stefan^2.
Received on 2011-07-04 23:58:14 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.