Folks,
We have two CMake variables, VTK_NO_PYTHON_THREADS and VTK_PYTHON_FULL_THREADSAFE. These are defaulted so that we don’t use GIL locking in ParaView builds by default. I am wondering if we should indeed enable Python thread support so that programmable filters can be written that use threading and other thread-based async features in Python.
Can anyone think of reasons why we shouldn’t?
Tomviz uses these options to force GIL locking in ParaView. A while ago I tried to set up a ParaView dashboard with these enabled, but there were some test failures I didn’t have time to solve at the time.
+1 from me for making these default
good to know. thanks!
+1
Well, using the GIL does have a small overhead for each python call, and that is why I did not enable it by default when I added the option.
Maybe a small performance check would be needed before putting this into the release.
a small overhead for each python call
We should not be making too many C+±2-Python calls in tight data processing loops, so that’s not a major concern. C+±2-Python path if often only for “plumbing”, setting up the pipeline, etc.
There is a separate issue where pvpython doesn’t seem to exit gracefully. I’ll track that down in time.
I thought we turned GIL off at the PV 5.0 transition because GIL was incompatible with some high profile python libraries? If my recollection is correct and that is still the case we still don’t want it on by default.