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

[Charl P. Botha]

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 p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/

c.p.botha ||at|| ewi.tudelft.nl - tu delft work-related email
cpbotha ||at|| cpbotha.net - everything else