> Aargh! I had an e-mail composed about that right away, > but didn't press send for fear of increasing the noise > level of Python-Dev even more. When you said saving of > state is a PITA, I figured you meant that this wasn't > going to work so easily. (Next time I'll at least send > a private e-mail.) Yes, I felt foolish :) Truly a case of "forest for the trees" - especially as I had working code I was referring to which did exactly this (even if it was in a C++ instance variable rather than a local :) > Should there be Py_BEGIN_AUTO_THREAD_STATE_ENSURE and > Py_END_AUTO_THREAD_STATE_ENSURE macros (analogous to > Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS) as well, > then? I'm not sure we can really get away with this. For C code, a common pattern will need to be: PyAutoThreadState_State state; .. some code state = PyAutoThreadState_Ensure(); ... more code PyAutoThreadState_Ensure(state); } We actually need all 3 blocks. Unlike Py_BEGIN_ALLOW_THREADS, we can't create a new scope to declare a local variable in, as that variable is needed by the outer most scope. I guess: Py_AUTO_THREAD_STATE_DECLARE Py_AUTO_THREAD_STATE_ENSURE Py_AUTO_THREAD_STATE_RELEASE would work. OTOH, in the code I am patching there already exists "#ifdef __cplusplus" - I am so tempted to add a tiny little extra block define a helper C++ class in the Python sources for managing this. However, if I do that I fear the Spanish Inquisition will look like a stroll in the park <wink> Could-do-it-in-2-lines-or-so 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