I believe the problem is that the interpreter retains the interpreter_lock
when it exits. In the standard Python interpreter, this is not a problem,
as the lock is released while the interpreter is waiting for input.
However, I am embedding Python in an application, and there is no
interpreter running.
My program is a GUI, and calls Python via the call_object API. The Python
event handler code creates a new thread, and it starts OK. Then the event
handler code exits, but with the interpreter lock still acquired. The
thread remains stalled on the lock. When another event handler is called,
the thread continues, etc.
I resolved this problem by doing the reverse of BGN_SAVE/END_SAVE. Before
calling the interpreter, I acquire the lock (thread_restore()), and after
call_object returns, I release it (thread_save())
However, this does not resolve all the problems. There are other ways the
interpreter is called that I can not intercept. print_error() is a problem,
but the biggest one hard to work around seems to be deleting objects. In my
specific example, when the user closes a window, a Python object is
DEC_REF'd. This may force destruction of the object, which may/will cause
the interpreter to be called, exiting with the lock in place.
Working around these is getting ugly, and some have no clean solution (eg,
the print_error should a thread exit with an exception). It would seem the
solution is to acquire/release the lock on interpreter entry/exit, as well
as the current scheme of releasing the lock while executing.
Does anyone have any comments on this??
Thanks,
Mark.