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.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-08-10 17:24:59 CEST