I working on a language interoperability tool called Babel, https://computation.llnl.gov/casc/components/. It provides high-performance, bi-directional communication between any combination of C, C++, F77, F90, Java, and Python. Right now, I am trying to make sure I am handling the GIL locking and unlocking correctly, and I am wondering if the Python community can confirm whether I am handling things appropriately.
Babel handles the many-to-many language interoperability problem with a hub and spoke architecture, so all inter-language calls go through C. Hence, I can discuss how I am handling the GIL in terms of communications between C and Python. I am going to describe what I am doing using pseudo-code and leaving out irrelevant details.
CASE 1 (some other language calling Python via C)
foo_Factorial(struct foo_t *self, int32_t arg) { /* C routine that calls Python */ PyGILState_STATE _gstate; _gstate = PyGILState_Ensure(); /* convert incoming arguments from C to Python */ _result = PyObject_CallObject(_pfunc, _args); /* process outgoing arguments or exceptions */ PyGILState_Release(_gstate); /* return to caller in whatever language */ }
CASE 2 (Python calling some other language via C)
static PyObject * pStub_foo_Factorial(PyObject *_self, PyObject *_args, PyObject *_kwdict) { PyObject *result; /* unpack incoming Python arguments into their C equivalents */ Py_BEGIN_ALLOW_THREADS /* dispatch to method implementation */ foo_Factorial(i,k,l); /* this step is actually done through a function pointer */ Py_END_ALLOW_THREADS /* pack outgoing C arguments into the Python return value or process any exceptions */ return result; }
Discussion
Case 1 seems pretty straight forward. The current thread must own the GIL before making any Python C API calls, and it should release it when it's done. Case 2 also seems appropriate because function x_y_Method could very well do blocking I/O operation. For example, Babel also supports remote method invocation (RMI), so x_y_Method might dispatch the method across the network to another machine.
In ceval.h where Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS are defined, it says "WARNING: NEVER NEST CALLS TO Py_BEGIN_ALLOW_THREADS AND Py_END_ALLOW_THREADS!!!". This makes me wonder if there is an issue with Python calling itself through Babel. Let's assume that Python is the main driver, and it calls a Babel wrapped Python method to calculate factorial or something. This will result in nested calls to PyGILState_Ensure/PyGILState_Release and Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS.
Python interactive shell (invokes foo.Factorial(3)) Py_BEGIN_ALLOW_THREADS (in pStub_foo_Factorial (case 2)) PyGILState_Ensure (in foo_Factorial (case 1) arg=3) Py_BEGIN_ALLOW_THREADS (in pStub_foo_Factorial (case 2)) PyGILState_Ensure (in foo_Factorial (case 1) arg=2) Py_BEGIN_ALLOW_THREADS (in pStub_foo_Factorial (case 2)) PyGILState_Ensure (in foo_Factorial (case 1) arg=1) PyGILState_Release (in foo_Factorial (case 1) arg=1) Py_END_ALLOW_THREADS (in pStub_foo_Factorial (case 2)) PyGILState_Release (in foo_Factorial (case 1) arg=2) Py_END_ALLOW_THREADS (in pStub_foo_Factorial (case 2)) PyGILState_Release (in foo_Factorial (case 1) arg=3) Py_END_ALLOW_THREADS (in pStub_foo_Factorial (case 2)) Python interactive shell
Is this approach correct?
Regards,
Tom Epperly LLNL/CASC