[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:
> >>>>> "Charl" == Charl P Botha <cpbotha at gmail.com> writes:
>     Charl> Is this allowed in C++?  I.e. if I'd create an observer in
>     Charl> one thread, and then add it to a VTK object in another
>     Charl> thread, does VTK guarantee that this will work?
> 
> I'm sorry but I don't see how this is an issue with C++ or VTK.  VTK
> sees the vtkPythonCommand object and that in turn routes the call
> through Python.  So what is the problem with VTK or C++ here?

I was trying to make the point that allowing something as fundamental
as this in VTK-Python while it is  not allowed or even defined in
VTK-C++ does seem to constitute over-engineering. Over-engineering
breaks things. :)

> I would think the vtkThreadManager would be just as easy to write and
> solves all the problems.  There is only one GIL, therefore only one
> *active* thread for Python at any point of time.  So you need to keep
> one stack of thread states and pop/append states into it.  When a VTK
> method call embedded inside an observer callback needs the lock, it
> releases the earlier lock, acquires it, does its thing, releases the
> lock and re-acquires the lock and sets the original state.

It would not be just as easy to write.  Ensuring that
vtkPythonCommands run in the same thread as the object that they are
observing is far easier and far less error-prone and doesn't require
an extra global data structure.

Imagine that you allow for observers in different threads.  Now
imagine what fun will ensue if one observer has been assigned to watch
two different VTK objects in two other threads.   Now imagine that
these two threads run concurrently and both trigger events at more or
less the same time in the same observer in a third thread.  One could
probably handle something like this, but currently I have my doubts as
to whether it's worth the extra complexity.

To my mind, it's all about what's possible vs. what's required.  I
prefer the latter. :)

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