[Python-Dev] GIL Pep commentary
Wed, 26 Feb 2003 09:59:34 +1100
> 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:
> "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
> "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
> 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?