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

[Prabhu Ramachandran]

>>>>> "Charl" == Charl P Botha <cpbotha at gmail.com> writes:

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

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

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

Well, thread-safety issues come with the territory and once you start
using threads you have to keep it in mind anyway.

Here is a simple scenario which I would think would be fairly typical
with just two threads.  Imagine that the GUI is in the main thread
(t0) and long-running VTK tasks run in a separate thread (t1).  Lets
say you'd like the UI to be notified when the long-running task does
something, like say a ProgressEvent.  Clearly, you'll want to give the
user feedback of the progress and therefore a natural way to do this
would be to listen for ProgressEvents in an observer running in t0 and
not t1.  So you have an observer in t0 listening to an object running
in t1.  I'd think this would be a common use case and it is important
that this works.  If you wish to disallow more than 2 threads, that is
fine.  But I would think the above does need to be supported.

Sorry to be such a pain, but you asked for comments. :-)

cheers,
prabhu