Tcl/Tk 9.0 released

Unfortunately, the correct procedure is rather path-dependent and can be complicated in some edge cases, which is probably why the PyGILState functions exist. Here are some examples:

* If Python previously called into you from the same thread, then that thread would usually be managed by Python, and so you probably already have the GIL. Then there would be nothing to do. The only exception I can think of is if you called into Python first (and then it called you back), which implies that you already figured out how to acquire the GIL, so just do whatever you did again.
* If Python previously called into you from a different thread, then you can use PyInterpreterState *interp = PyInterpreterState_Get() to get the current interpreter, and then (on the new thread) call PyEval_RestoreThread(PyThreadState_New(interp)) (error checking elided). When you're done calling into Python, you will probably want to call PyThreadState_Clear(PyThreadState_Get()); PyThreadState_DeleteCurrent() to free the object created by PyThreadState_New() (and implicitly release the GIL). If you want to keep it around for multiple calls into Python, you can use PyEval_SaveThread()/PyEval_RestoreThread() to release and re-acquire the GIL in the usual manner (and you can also use the Py_BEGIN_ALLOW_THREADS convenience macro), but you should eventually free it when finished calling into Python. You need a separate thread state object for each thread that will call into Python (technically, you need one for each thread-interpreter combination, but I'm assuming you're not planning to interleave interactions with multiple interpreters on a single thread, because then you have to use PyThreadState_Swap() and the complexity really starts to make your code hard to read).

Frankly, those two bullets cover the vast majority of "real" use cases. But for full feature parity, there's a long tail of other cases to consider:

* If Python did not previously call into you at all, then you have a couple of further options. You could use the "main" interpreter, which is the first interpreter initialized for the process, as returned by PyInterpreterState_Main(), but that's really only suitable if you're not going to interact with any pre-existing Python objects and just need an arbitrary interpreter. In that case, it is probably preferable to create your own private sub-interpreter instead, preferably with its own private GIL (which you can do by acquiring the main interpreter's GIL and then using Py_NewInterpreterFromConfig(...) to create the sub-interpreter). OTOH, creating lots of tiny interpreters is probably not optimal either, so there's a certain amount of nuance here. You may need to experiment with different setups and benchmark the performance. Creating a private interpreter is most likely to be worth it if you know that the rest of the process is making extensive use of the main interpreter (or some sub-interpreter which shares the main's GIL), and least likely if you're the only code in the whole process calling into Python.
* The other possibility is that you know which interpreter you want, because you created it in the first place. But then this reduces to the "Python previously called you from a different thread" case, since creating an interpreter puts your thread into (more or less) the same state as if Python just called into it from that interpreter. It also implicitly releases the parent interpreter's GIL (if you request a separate GIL for the child interpreter), so you need not worry about doing that.
* PyGILState_Ensure() can also be called recursively if you do not know whether you hold the GIL, and so for full parity, we need to have a way to check whether you have the GIL already (to avoid self-deadlock in the case that you do have the GIL). You can use PyGILState_Check() for that, and unlike the rest of the PyGILState API, this ought to be reasonably compatible with multiple interpreters. That's because it is reading the same thread-local variable that the rest of the PyThreadState API interacts with, so it should not "care" whether you are acquiring the GIL via PyGILState or with the interpreter-aware functions. The caveat is that it is possible to clear this variable without actually releasing the GIL (e.g. with PyThreadState_Swap()), in which case this function can lie to you. So don't do that and then try to query whether the GIL is held - PyThreadState_Swap() requires holding the GIL anyway, so I'm not entirely sure there's even a use case for doing this in the first place.
* Believe it or not, we're still not done, because recursive calls to PyGILState_Ensure() can be interleaved with the rest of the PyThreadState API, including PyEval_SaveThread(), so it also has to check for that case explicitly and re-acquire the lock if it has been released since the last call. I'm... not really sure why you would do that, but apparently it is a thing you can do.
* Note also that Python's thread-local storage API does not require holding the GIL to use, and supports arbitrary (void*) types, so you can record additional information there if it is useful to do so (which is exactly how PyGILState works internally - it maintains a counter of how many times you have called into it in order to figure out when to destroy the thread state, and this system is even designed to avoid destroying manually-created thread states so that it can be safely interleaved with PyThreadState_New() and company).

Fair warning: I have read the documentation for these functions. I have not actually tried to write code against them. I did read some of CPython's source code to spot-check a few points of uncertainty, and I'm fairly sure that most if not all of the above is basically correct (in particular: PyGILState_Ensure() does indeed call PyEval_RestoreThread() to acquire the GIL if necessary, so I'm reasonably convinced that it is legal to create a new thread state from scratch and "restore" it), but it is always possible that I have missed something.