Embedding Pythonwin: Thread State Problems with Nested Calls

[Robert Kiendl]

I've got just one thread - for app and pythonwin.

When win messages are routed to the pythonwin part of my application,
execution flows through a CEnterLeavePython/PyEval_AcquireThread (inside
CVirtualHelper, glue/Python_OnCmdMsg, ...)

Also direct calls of python code out of the app source appears. Such
stuff must also be sourrounded by CEnterLeavePython (i think this is
rigth?)

Sometimes such CEnterLeavePython-sourrounded direct python calls run
back into windows functions which directly send messages (SetWindowPos,
DoModal's, ....) When such Messages run through the above path,
PyEval_AcquireThread ist called a second time inside pythonwin - and
bang!

What would be a correct treatment for those problems? 

Finding all win-reentries in my swig-ed code and doing
y_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS would be tedious and
apparently unnecessary.

Experiments with glue.bShouldAbandonThreadState=false were fruitless.

Is that thread state handling of Pythonwin already in a ripe state or is
this a current topic?

I hate trying to compile pythonwin with PYCOM_USE_FREE_THREAD or such
stuff. Would this at all be a makeshift?

Or am i completly wrong?

robert