[Python-Dev] Change definition of Py_END_ALLOW_THREADS?

Mark Hammond mhammond@skippinet.com.au
Fri, 14 Feb 2003 09:11:22 +1100


> 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.