> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4