[Python-Dev] GIL Pep commentary

[Mark Hammond]

> I just started looking over the GIL pep
> http://www.python.org/peps/pep-0311.html. Looks pretty nice to me so
> far!  I have these remarks:

Great!

>    "This API will not perform automatic initialization of Python, or
>     initialize Python for multi-threaded operation.  Extension authors
>     must continue to call Py_Initialize(), and for multi-threaded
>     applications, PyEval_InitThreads()."
>
> This is liable to confuse people (like me) who have never had to do
> Py_Initialize or PyEval_InitThreads in their extension modules.

Good point.  I will change "Extension Authors" to "Applications which embed
Python"

>    "It is intended that this API be all that is necessary to acquire
>     the Python GIL.  Apart from the existing, standard
>     Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS macros, it is
>     assumed that no additional thread state API functions will be used
>     by the extension.  Extensions with such complicated requirements
>     are free to continue to use the existing thread state API."
>
> This sounds like it's saying you can't use any of the old thread API
> functions if you use the new ones.  Is that right?  If so, I think it
> should be made more explicit.  Seems a bit draconian, though I admit I
> don't know what other thread API functions people might want.

That is kind-of what I mean <wink>.  My concern is simply that I did not
want to make this code totally bullet-proof in the face of all the tricks
that can be pulled with the existing thread-state API.  For example, the
existing API allows you to switch as many different thread-states in for a
single thread that you desire.  I am really not sure what my patch would do
if the developer goes and swaps thread-states underneath our API.

I guess all I am saying is: If you use other thread-state APIs in
conjunction with this new API, it is your responsibility to make sure
everything works!

> Good job, Mark!

Thanks!  And while we are here, do you have any suggestions for the name, as
per the start of the PEP?

I am starting to think PyThreadState_Ensure() and PyThreadState_Release()
are good enough names.  The only problem is that they are not really part of
the same "family" as the other PyThreadState_* functions, and thus people
may assume they can mix-and-match them.  OTOH, they clearly are ThreadState
related functions, so are at least cousins to the rest of them!

As far as I can tell, there are no technical issues remaining in this PEP -
only naming and clarification.  Does anyone disagree with that?

Keen-to-get-this-in-2.3 ly,

Mark.