Closed GoogleCodeExporter closed 9 years ago
Original comment by cpbotha
on 4 Dec 2008 at 1:04
Original comment by cpbotha
on 23 Dec 2008 at 5:36
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
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
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
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
Original issue reported on code.google.com by
cpbotha
on 18 Sep 2008 at 4:31