Here's the double lock I'm afraid of: 1. Embedding program invokes some Python code with its embedded interpreter 2. The embedded interpreter, through running that code, ends up executing some code actually in the embedded program's environment. 3. This code back in the embedded program has another thread (here we go) that calls to some interfaces, of which one is written in Python. 4. The wrapper needs to acquire the GIL since it's going back into Python, and it's going into it from another thread entirely.
At #4 right there I thought it was tricky when trying to do this. I guess the important thing to do is to make sure to store a unique state from each call to PyGILState_Ensure and to keep those in order when using PyGILState_Release. I think when I originally did this, I had a global pointer, which was bad news. I wanted to make sure I understand how to handle a particularly disruptive situation when embedding Python in another language. I've been following this with embedding Python in C++, and I also looked at this with embedding CPython in C# using Python.NET. The Python.NET library looks like it's surviving without double locking. Looking at its implementation, I wanted to review for posterity's sake how this is supposed to work. I know when I was first trying to do this in C++, I didn't really pull it off, and I wanted the next poor fool that's Googling for this to have a good shot at it. So do I have it?
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
