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

Re: [PATCH] svn_client_ctx_t callback fixes, mark 3

From: Walter Mundt <emage_at_spamcop.net>
Date: 2006-06-05 00:25:47 CEST

Walter Mundt wrote:
> David James wrote:
>>> (svn_swig_py_pool_set_owned_ref): New helper function to manage pool
>>> "owned references."
>>
>> To quote the documentation: This function "replaces an 'owned
>> reference' allocated in a pool from oldRef to newRef. If oldRef is
>> non-NULL and present in the parent pool of proxy, it is removed."
>>
>> The replace operation in svn_swig_py_pool_set_owned_ref function is
>> atomic and thread-safe, assuming that the caller is holding the Python
>> global interpreter lock. (Is this a safe assumption to make?)
>
> I actually don't think it necessarily is. This function and several
> other helpers that are used in typemaps (most notably
> svn_swig_MustGetPtr) get called either before or after the block of code
> where the Python GIL is acquired in the generated code, but can execute
> arbitrary Python code. (At least here/on my version of swig.) In the
> case of proxy object getters and setters, the Python GIL is never
> acquired at all.
>
> While that seemed wrong to me, I decided not to worry about it for now,
> since the bindings currently do this and work anyway. Another patch for
> another day, assuming you don't pull another swig magic trick out of
> your hat that says the GIL is already acquired before calling some of
> these generated functions. (If you do that, then the code to
> acquire/release the GIL is inserted redundantly in a number of places.)

Just to clarify for the list, I had this completely backward in my head.
  CPython extension functions own the Python GIL by default and must
release it if they don't want it. The bindings' current behavior is
correct, and djames's assumption above is safe after all.

-Walter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 5 00:27:04 2006

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.