[vtkusers] vtkRenderWindowInteractor.Start() blocks unrelated threads?

[Charl P. Botha]

On 2/1/07, Martin Ling <martin-vtk at earth.li> wrote:
> The following python script sets up a simple VTK pipeline, then launches
> a separate thread which does not interact with any of the VTK objects -
> it just prints to standard output.
>
> When run, UPDATE 0 is printed, but once the Start() method on the
> RenderWindowInteractor is called, the second thread stops. Only when the
> render window is closed does the other thread start printing again.
>
> This occurs under both VTK 4.2 on Win32 and VTK5.0 on Linux.

Welcome to the world of controversy that is the Python global
interpreter lock, lovingly called the GIL.  A single Python
interpreter does not allow more than one thread's bytecodes to execute
concurrently.

Wrapped C++ code that does not make any Python API calls can give up
the GIL, thus giving other Python threads some execution time, but VTK
does not do this.  I made a patch for this a long time ago, but never
completed the work...   read this thread for the back-story:
http://public.kitware.com/pipermail/vtk-developers/2005-June/003331.html

In short: at this very moment you're going to have to choose a
concurrency approach other than threads, if you want to do this in
Python.