I am using large parts of ParaView’s libraries in Tomviz, and we run many Python operations in background threads. As an application we have no use for the tracing functionality, but we came to realize it is always there recording many ParaView API calls. The Python GIL causes many locks when calling API if there are background tasks running due to the use of vtkPythonScopeGilEnsurer in vtkSMTrace.cxx. I just tried patching this file locally to enable Python code if PARAVIEW_ENABLE_PYTHON_TRACE rather than reusing PARAVIEW_ENABLE_PYTHON.
In initial testing it looks like everything is nicely contained in this file, would the ParaView community be open to the addition of an advanced CMake flag to disable Python tracing even when Python wrapping is enabled, or is there a way to disable tracing altogether that I simply missed and should have skipped this whole exercise in the first place? I know ParaView may not want to build in this way, but it seems reasonable to be able to disable this functionality for consumers of the APIs who are not making use of it and working around GIL issues.
I don’t think it should be a compile-time option, but instead a runtime option. I’d like to avoid adding new “yeah, you just have a half-useful build of library X” instances to the codebase.
It is already protected by a bunch of ifdefs, and it looks to me like it should never have been implicitly linked to the act of enabling Python wrapping in the first place. I am not sure where “half-useful build” comes from, as a consumer of the API that is what I currently have, and am looking for a simple way to improve it rather than working around GIL issues for a feature I derive no benefit from.
The more I look at the code it really doesn’t matter much, so yeah if there is a preference from the ParaView side for runtime it will be a little more work but we could do it. This is a static function, so it would need to be a static bool, I guess default to on to preserve current behavior, then effectively protect all calls within the ifdef blocks with an if (EnablePythonTracing) ...
If that sounds acceptable I can get a patch together. I will give it a few days, I can’t imagine any side effects. The call to disable should likely be made earlier. I wonder if it might be useful to disable all tracing in addition, but the Python GIL calls are the ones causing deadlocks in the use cases I am looking at, so that would be enough.