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

[Charl P. Botha]

On 6/17/05, Prabhu Ramachandran <prabhu_r at users.sf.net> wrote:
> The trouble being that you can only save the state if the current
> thread is the one that acquired the lock.  This may or may not be
> true.  So if all VTK objects are created in one thread, I think we are
> OK, but if that is not the case, I don't think this will work.  So if
> `b` lives on a different thread, I think this won't work.  I think a
> simple test case could be engineered to check this out.  I could be
> wrong though because I haven't thought through it enough.

I really don't think that we have to support someone adding a Python
observer from a different thread to a VTK object in another thread.   
That would require far too much surgery and would in my opinion be
over-engineering.  All other threaded libraries require very careful 
consideration when one attempts inter-thread communication.

With the current solution (more or less), VTK objects can be in
different threads, as long as observers and the VTK objects that they
observe are in the same thread.

> I'm thinking aloud here, but would this work? Create a
> vtkThreadManager that manages acquiring and releasing the GIL.  When a

IMHO, this is going one level of abstraction too far. :)


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