[vtk-developers] Patch to vtkWrapPython.c to make wrapped Python code GIL-friendly

[Prabhu Ramachandran]

>>>>> "Charl" == Charl P Botha <cpbotha at gmail.com> writes:

    Charl> Dear list, On 6/16/05, Charl P. Botha <cpbotha at gmail.com>
    Charl> wrote:
    >> Okay, it was a bit more complex than I thought.  In order to
    >> re-acquire the lock in the observer, I need the PyThreadState
    >> of the object that is being observed.  I had to inject this
    >> into the vtkPythonCommand instance itself.

    Charl> Attached is the latest version of the patch.  The
    Charl> vtkPythonCommand now gets and stores the PyThreadState in
    Charl> its constructor.  This is much simpler than the previous
    Charl> explicit storing by the wrapping code.

I'm no GIL/Python threading expert but I am not too comfortable with
this latest approach.  I am not sure that the thread state is going to
be identical between the creation of the observer and its invocation.
You save the thread state at the time vtkPythonCommand is instantiated
and use that saved state when Execute is called.  Are you certain that
there is no way for the state to have changed in the meanwhile?  I
looked at pystate.h and from what I can understand, PyThreadState is a
non-trivial structure that could have changed between the time of
creation of vtkPythonCommand and its Execution.

The second issue is, what if the observer triggers another callback in
the same thread?  Don't you run into a deadlock with both
vtkPythonCommands calling `PyEval_AcquireLock()`?  For example, lets
vtk object `a` has an observer `fa` and in `fa` you modify some vtk
object `b` and that in turn has another observer listening for the
Modified event of `b`.  You don't release the lock until `fa` returns
but `fa` triggers another event, which will try to acquire the lock
and you end up with deadlock, right?

I hope I am not missing something obvious here.  I guess threading
issues can be hairy.

cheers,
prabhu