-> But this dodges the question, why isn't Quixote thread safe out of the
-> box?  Is it really that much overhead to merge thread.get_ident() and a
-> request dictionary into the Publisher?  Quixote is generally server
-> agnostic, why does it have a bias against threaded servers?

My suspicion is that the Quixote developers mainly work with SCGI (as do
I, these days) and don't want to have to test thread-safety.  I
personally would rather not worry about thread-safety when I don't
want to run it in multithreaded mode.

(It's ironic that I'm saying this, given that I requested the original
thread-safety code in Quixote Way Back When, because of PyWX ;).

-> >QWIP should also (by default) complain about being put in a
-> >multi-threaded environment; env['wsgi.multithread'] is probably
-> >the right way to check this.
->
-> Who should do what here?  QWIP should really ask Quixote if it's thread
-> safe rather than assuming it isn't.  Can Publisher add an
-> .is_thread_safe flag for QWIP to check?  And what should QWIP do if the
-> threading models are incompatible?  It's too bad the PEP doesn't have
-> exceptions defined for these situations.

For the nonce, why not have QWIP check wsgi.multithreaded and raise an
exception if it's true, and then if Quixote gets retrofitted to provide
thread-safety info we can have it rely on that?

cheers,
--titus