[Python-Dev] Change definition of Py_END_ALLOW_THREADS?

[Gerald S. Williams]

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