-> 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 _______________________________________________ Quixote-users mailing list [email protected] http://mail.mems-exchange.org/mailman/listinfo/quixote-users
