"Unfortunately, given that Cython-based libraries are incompatible with sub-interpreters, and given that mod_wsgi uses sub-interpreters, it follows logically that Cython-based libraries like lxml are incompatible with simple mod_wsgi configurations. In our case, this manifested as a single-thread self-deadlock in the Python Global Interpreter Lock whenever we tried to use our application at all. "
The simple workaround given in that page (forcing a single WSGI application into the global application group) resolves the problem for me. I don't know anything about the mod_wsgi daemon processes mentioned as an alternative, so I didn't try them. But I think this is pretty strong evidence that the problem is a conflict between two non-Beautiful-Soup pieces of software. As such, I'm marking this bug WONTFIX.
I'm able to reproduce. Some more information:
* The presence of a virtual environment doesn't matter.
* The reference Python WSGI environment does not have the problem. Apache mod_wsgi does.
I believe this is an instance of the interaction between mod_wsgi and Cython described here:
https:/ /techknowhow. library. emory.edu/ blogs/branker/ 2010/07/ 30/django- lxml-wsgi- and-python- sub-interpreter -magic
"Unfortunately, given that Cython-based libraries are incompatible with sub-interpreters, and given that mod_wsgi uses sub-interpreters, it follows logically that Cython-based libraries like lxml are incompatible with simple mod_wsgi configurations. In our case, this manifested as a single-thread self-deadlock in the Python Global Interpreter Lock whenever we tried to use our application at all. "
The simple workaround given in that page (forcing a single WSGI application into the global application group) resolves the problem for me. I don't know anything about the mod_wsgi daemon processes mentioned as an alternative, so I didn't try them. But I think this is pretty strong evidence that the problem is a conflict between two non-Beautiful-Soup pieces of software. As such, I'm marking this bug WONTFIX.