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

Charl P. Botha cpbotha at gmail.com
Fri Jun 17 08:26:54 EDT 2005


On 6/17/05, Prabhu Ramachandran <prabhu_r at users.sf.net> wrote:
> 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.

You're most probably right... the previous patch wasn't much better. 
The best place to store the thread state would be in the wrapping code
right before the lock is given up and the long-running VTK method is
initially called.  I'll have to see if I can find a place to squirrel
away the threadstate at that moment.

> 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.

Cheerio,
Charl

-- 
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



More information about the vtk-developers mailing list