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

[David Gobbi]

Charl P. Botha wrote:

>On 6/17/05, Charl P. Botha <cpbotha at gmail.com> wrote:
>  
>
>>On 6/17/05, Prabhu Ramachandran <prabhu_r at users.sf.net> wrote:
>>    
>>
>>>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?
>>>      
>>>
>>You're right again.  AFAICS, there's also no way to check if the
>>current thread already has the lock: that would have solved the
>>problem.
>>
>>I'm going to have to think about this more; it's almost beginning to
>>look like there's no straight-forward and fail-safe way to do this,
>>but that it all has to be terribly complex by definition. :)  I'd
>>appreciate any more insights that you might have.
>>    
>>
>
>Wait, maybe you're not right on this point after all. :)  Remember
>with my patch, ALL VTK calls release the GIL.  So, if observer 'fa'
>(which has the lock when it's executing) modifies any other object
>'b', the lock is released for EVERY VTK method that's called.  My
>reasoning is based on the assumption that vtkPythonCommand::Execute()
>can ONLY be called from VTK C++ code, and that all VTK C++ code is
>running WITHOUT GIL due to my patch.  This means that ::Execute() HAS
>to acquire the lock.
>
>What do you think?
>  
>
Charl, I think you're right on this point.  An observer is always called 
from VTK,
and as long as the lock is always released on every transition from 
Python code
to VTK code, everything should be fine.

On the other point about observers being called from a different thread 
than the one
that set the observer, it seems that you need to maintain a data 
structure that keeps
track of all the python thread structs and you need some way of figuring 
out which
one to use when an observer is called.  It definitely sounds doable to me.

 - David