Mark Hammond wrote:
> 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.
If you say so, I'll take your word for it, although your
example seems to contradict what you're saying--i.e., it
makes it look like this would work:
{
... some code
{ PyAutoThreadState_State state = PyAutoThreadState_Ensure(); /* BEGIN */
... more code
PyAutoThreadState_Ensure(state); } /* END */
}
> I guess:
> Py_AUTO_THREAD_STATE_DECLARE
> Py_AUTO_THREAD_STATE_ENSURE
> Py_AUTO_THREAD_STATE_RELEASE
>
> would work.
If you need the declaration, I'd vote for making it
explicit. I only suggested the macro for consistency
with what's been done before.
> 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>
I've been thinking about a related use for __cplusplus: in
C++ (or C99 for that matter), the extra scope declaration in
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS isn't needed. I
wonder if it would be worth removing the braces from those
macros when possible. It would be just a matter of principle,
I guess--putting braces in macros like that is generally
frowned upon in polite company. ;-)
-Jerry
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