imageMathematics should check that its two inputs have the same type

[GoogleCodeExporter]

vtkImageMathematics seems to deadlock with two inputs that have different
types, UNLESS you do SetNumberOfThreads(1).

To prevent this, do a sanity check on input types during set_input()

Original issue reported on code.google.com by cpbotha on 18 Sep 2008 at 4:31

[GoogleCodeExporter]

Original comment by cpbotha on 4 Dec 2008 at 1:04

• Added labels: Milestone-Release8.12

[GoogleCodeExporter]

Original comment by cpbotha on 23 Dec 2008 at 5:36

• Added labels: Milestone-Release9.1

[GoogleCodeExporter]

Ouch, it looks like this might have to do with my vtkPythonUtil.cxx work to 
turn 
vtkErrorMacros into exceptions.

To reproduce:
* vtkImageMathematics, two inputs of different types
* the image math does a vtkErrorMacro in ThreadedRequestData that runs in 
multiple 
threads and then...
* it SEEMS to be blocking in my vtkPythonOutputWindow, *probably* with 
PyGILState_Ensure.

Why do for example progress messages (done via the vtkPythonCommand) NOT block? 

These are also called from threaded bits, also with PyGILState_Ensure.

If number of threads is set to 1 on the offending modules, all works perfectly.

Can't debug this right now, I'm in Magdeburg with only laptop.  Need fast 
machine.

Original comment by cpbotha on 8 May 2009 at 3:16

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Hypothesis:

When Python calls into long-running single-threaded VTK methods, there is no 
problem 
with an error, because it's happening in the same thread.  However, if it's 
happening 
in a different thread, it tries to acquire the lock with PyGILState_Ensure and 
waits 
forever, because the main thread never gave up the GIL when invoking the method 
in 
the first place.

This could be solved by bracketing all calls into VTK with 
Py_BEGIN_ALLOW_THREADS and 
Py_END_ALLOW_THREADS, which would give up the GIL (thus enabling Python to go 
its 
merry way whilst VTK is busy), and would allow the error handler to grab the 
lock in 
order to do its business.

I still can't explain why progress outputting (i.e. the vtkPythonCommand 
observer) 
does work even in the multi-threaded situation.

Original comment by cpbotha on 8 May 2009 at 3:41

[GoogleCodeExporter]

Now I can explain it:

UpdateProgress() is only called from the first thread!  See:

      if (!id)
        {
        if (!(count%target))
          {
          self->UpdateProgress(count/(50.0*target));
          }
        count++;
        }

id is the thread id.

So, my hypothesis could just be correct...

Original comment by cpbotha on 8 May 2009 at 3:58

[GoogleCodeExporter]

Fixed in r3509 by patching the VTK wrapping system to give up the GIL around VTK
method calls.  MUCH better. :)

Original comment by cpbotha on 21 May 2009 at 9:29

• Changed state: Fixed