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

Re: svn commit: r1154393 - in /subversion/branches/fs-py/subversion: libsvn_fs_py/fs.c libsvn_fs_py/fs.h libsvn_fs_py/fs_fs.c libsvn_fs_py/py_util.c libsvn_fs_py/py_util.h python/svn/fs.py

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Wed, 10 Aug 2011 10:24:29 -0500

On Mon, Aug 8, 2011 at 4:27 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Mon, Aug 8, 2011 at 15:33, Hyrum K Wright <hyrum.wright_at_wandisco.com> wrote:
>>> First off: we can ignore the specific calls to make it work, but
>>> structurally you want something like our *_with_transaction() type of
>>> invocation. For every FS vtable entry, it will use this (say)
>>> svn_fs_py__invoke_python() call. We can then build the appropriate
>>> acquisition of any locks necessary.
>> I arrived at a similar conclusion in thinking about the problem over
>> the weekend.  The current svn_fs_py__call_method() function has
>> something of the like to provide error wrapping, and could be either
>> nested or extended to handle the correct locking semantics.
> Excellent. As long as that is guaranteed as the bottleneck, then
> that's where the focus for proper embedding will live.
>> In our (current) case, we're only using one thread, the main thread,
>> so I wonder whether we need to worry about interpreter states and
>> thread states and the like.  (This is an honest question, as in my
>> naïveté probably don't understand all the nuances here.)  It sounds
> Think about the server. You're running inside Apache. You have
> multiple threads. Some of those threads are fs_py, and some of those
> are mod_python.
> Proper locking and isolation are definitely necessary.

Does this also mean that we shouldn't call Python_Finalize(). I'd
hate to shutdown the Python system when it's still being used by
another thread in our process...

>> like you're implying that we can't guarantee that "our" interpreter is
>> the only one running, and so must start concerning ourselves with the
>> GIL and such.
>> Another thought along these lines is that we'll be calling back from
>> Python into C via the callbacks, such as the delta editor.  Since
>> those callbacks are outside our control, and may be long-running, if
>> we do use the GIL, would it be appropriate to release it upon entering
>> a C callback, and then acquire it upon exit?
> Correct.
> You'll see this in the SWIG helper functions. They release the GIL,
> call $functions, re-acquire the GIL, and return to Python. You will
> want to do the same for all areas where fs-py calls back into C. My
> recommendation is to simply rely on the SWIG bindings. The fs-py code
> can use the SWIG bindings to make the appropriate calls, and those
> will handle the GIL properly. You only need to worry about the GIL
> from an embedding standpoint, rather than a call-out standpoint.

Okay, that's what I thought.


uberSVN: Apache Subversion Made Easy
Received on 2011-08-10 17:24:59 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.