[Xapian-tickets] [Xapian] #185: Deadlocks with apache mod_python and mod_wsgi
Xapian
nobody at xapian.org
Sun Jul 20 10:47:19 BST 2008
#185: Deadlocks with apache mod_python and mod_wsgi
-----------------------------+----------------------------------------------
Reporter: richard | Owner: richard
Type: defect | Status: assigned
Priority: normal | Milestone:
Component: Xapian-bindings | Version: SVN HEAD
Severity: normal | Resolution:
Keywords: | Blockedby:
Platform: All | Blocking:
-----------------------------+----------------------------------------------
Comment(by richard):
The Python 2.3 problem definitely did exist with Xapian, and I think it
still does: last year, when this issue was first opened, I observed it
failing as described, and the Xapian code is exactly as described in the
http://issues.apache.org/jira/browse/MODPYTHON-217. To pick a random
example, the wrapper function for xapian.version_string() begins:
{{{
SWIGINTERN PyObject *_wrap_version_string(PyObject *SWIGUNUSEDPARM(self),
PyObject *args) {
PyObject *resultobj = 0;
char *result = 0 ;
SWIG_PYTHON_THREAD_BEGIN_BLOCK;
}}}
and SWIG_PYTHON_THREAD_BEGIN_BLOCK eventually expands to a call to
PyGILState_Ensure(). This is called with the interpreter holding the GIL,
and the situation is the same for pretty much every SWIG generated method,
so any call to xapian results in deadlock.
I don't have a Python 2.3 installation to hand to test this now, but the
Xapian code hasn't changed, and I assume the mod-python code hasn't
either, since the MODPYTHON-217 issue in the apache tracker is still open.
I therefore believe the summary in this bug about the situation with 2.3
is correct.
With python 2.4, it is still necessary to set the interpreter to
main_interpreter, as described at length in
http://issues.apache.org/jira/browse/MODPYTHON-77 - this is because any
use of PyGILState_Ensure() assumes that the interpreter running is the
main interpreter. Also, as you describe in your comment, callbacks to
Python from C still won't work. I think our "Summary of current known
status" is therefore fully up-to-date and correct.
I don't understand your comment "BTW, not compiling SWIG bindings with
thread support would preclude callbacks." If swig is told to generate the
bindings without thread support, the resulting code doesn't touch the GIL
at any point, so the callbacks should work fine (the lock is never
released, or re-acquired, but the thread state isn't accessed either). I
fully agree with "Plus, if C code blocked for long time, would cause all
of Python to block as GIL not released for case 1 above", though!
--
Ticket URL: <http://trac.xapian.org/ticket/185#comment:31>
Xapian <http://xapian.org/>
Xapian
More information about the Xapian-tickets
mailing list