(The last line, and the <unfinished> before it, only seem to appear when the process times out).
The lxml code has some locking that only happens when threading is enabled, so that may explain why I didn't see this when I straced just the call in a python interpreter. The wsgi process does indeed run with threads, and if what we see here is multiple threads vying for the same lock, there may be a deadlock condition.
There is no busy-waiting: the lxml call is properly waiting. Here's what I get when I strace the application at this point:
31418 futex(0xb93c0248, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
31417 <... select resumed> ) = 0 (Timeout)
31417 futex(0xb93c0248, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
31416 <... select resumed> ) = 0 (Timeout)
(The last line, and the <unfinished> before it, only seem to appear when the process times out).
The lxml code has some locking that only happens when threading is enabled, so that may explain why I didn't see this when I straced just the call in a python interpreter. The wsgi process does indeed run with threads, and if what we see here is multiple threads vying for the same lock, there may be a deadlock condition.