[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: Greg Stein <gstein_at_gmail.com>
Date: Mon, 8 Aug 2011 17:27:05 -0400

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.

> 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?


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.

Received on 2011-08-08 23:27:34 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.