A third use is the Reset button on the python shell. The reset button is also triggered when you disconnect from a server. The reset button is implemented by destroying the interpreter and creating a new one.<br><br>Pat<br>
<br><br><div class="gmail_quote">On Fri, Aug 3, 2012 at 5:13 PM, Utkarsh Ayachit <span dir="ltr"><<a href="mailto:utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pat,<br>
<br>
I am not surprised. I remember running into this ages ago. If I<br>
remember correctly, here are the two use-cases for Python in ParaView:<br>
<br>
* Qt Python testing uses the python interpreter from a separate thread<br>
* Python shell, Programmable Filter use Python interpreter from master<br>
thread but they need separate scopes.<br>
<br>
So long as these use-cases can be satisfied, it would make sense to<br>
not rely on Py_NewInter... if possible.<br>
<br>
Utkarsh<br>
<br>
p.s. flying today, so we can talk more on Monday, if you'd like.<br>
<div><div class="h5"><br>
On Fri, Aug 3, 2012 at 2:16 PM, Pat Marion <<a href="mailto:pat.marion@kitware.com">pat.marion@kitware.com</a>> wrote:<br>
> I am using numpy 1.6.1 and scipy 0.9.0 via system packages python-numpy and<br>
> python-scipy on Ubuntu 12.04. In both the paraview python console and<br>
> programmable filter, importing certain scipy modules, for example,<br>
> scipy.stats, causes paraview to hang. This issue is related to the python<br>
> global interpreter lock (GIL), the program hangs on PyGILState_Ensure().<br>
> Here is the backtrace:<br>
><br>
><br>
> #0 sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86<br>
> #1 0x00007ffff1e90c28 in PyThread_acquire_lock () from<br>
> /usr/lib/libpython2.7.so.1.0<br>
> #2 0x00007ffff1e91b34 in PyEval_RestoreThread () from<br>
> /usr/lib/libpython2.7.so.1.0<br>
> #3 0x00007ffff1e58d08 in PyGILState_Ensure () from<br>
> /usr/lib/libpython2.7.so.1.0<br>
> #4 0x00007fffca31ffc6 in ?? () from<br>
> /usr/lib/python2.7/dist-packages/numpy/core/umath.so<br>
> #5 0x00007fffca320357 in ?? () from<br>
> /usr/lib/python2.7/dist-packages/numpy/core/umath.so<br>
> #6 0x00007fffca337633 in ?? () from<br>
> /usr/lib/python2.7/dist-packages/numpy/core/umath.so<br>
> #7 0x00007fffca337ac6 in ?? () from<br>
> /usr/lib/python2.7/dist-packages/numpy/core/umath.so<br>
> #8 0x00007ffff1e47e83 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0<br>
> ...<br>
><br>
><br>
> This could be a bug in scipy/numpy. The issue does not appear for older<br>
> versions of numpy/scipy. But, it is likely caused by the interaction with<br>
> ParaView's usage of Py_NewInterpreter. The paraview class<br>
> vtkPVPythonInterpretor uses the Python C-API function Py_NewInterpreter in<br>
> order to create insulated interpreters. The documentation for<br>
> Py_NewInterpreter warns users to be very careful mixing it with the GIL.<br>
> For example, it says:<br>
><br>
> "Note that the PyGILState_*() functions assume there is only one global<br>
> interpreter (created automatically by Py_Initialize()). Python supports the<br>
> creation of additional interpreters (using Py_NewInterpreter()), but mixing<br>
> multiple interpreters and the PyGILState_*() API is unsupported."<br>
><br>
> and<br>
><br>
> "Also note that combining this functionality with PyGILState_*() APIs is<br>
> delicate, because these APIs assume a bijection between Python thread states<br>
> and OS-level threads, an assumption broken by the presence of<br>
> sub-interpreters."<br>
><br>
> ( <a href="http://docs.python.org/c-api/init.html" target="_blank">docs.python.org/c-api/init.html</a> )<br>
><br>
><br>
> Perhaps it is possible to work around this particular hangup by compiling<br>
> numpy/scipy with threading disabled or some other flag to disable their<br>
> usage of the GIL. But, ParaView's usage of Py_NewInterpreter also makes it<br>
> difficult to use other libraries correctly, like PyQt4 or PySide for<br>
> example. I that at some in the future we might want to consider removal of<br>
> Py_NewInterpreter from paraview.<br>
><br>
><br>
> Pat<br>
><br>
</div></div>> _______________________________________________<br>
> Paraview-developers mailing list<br>
> <a href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><br>
> <a href="http://public.kitware.com/mailman/listinfo/paraview-developers" target="_blank">http://public.kitware.com/mailman/listinfo/paraview-developers</a><br>
><br>
</blockquote></div><br>