On Mon, Aug 8, 2011 at 4:27 PM, Greg Stein <gst...@gmail.com> wrote: > On Mon, Aug 8, 2011 at 15:33, Hyrum K Wright <hyrum.wri...@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/
