durusmail: quixote-users: wsgi_server.py for Quixote
wsgi_server.py for Quixote
2005-04-29
2005-04-30
2005-04-30
2005-04-30
2005-04-30
2005-04-30
2005-04-30
2005-04-30
2005-04-30
2005-04-30
2005-04-30
2005-05-01
2005-05-01
2005-05-01
2005-05-02
2005-05-01
2005-05-01
2005-04-30
2005-04-30
2005-04-30
wsgi_server.py for Quixote
Mike Orr
2005-04-30
Titus Brown wrote:

>-> Is there reason to believe that quixote applications will work reliably
>-> under this multi-threaded server?   I wouldn't expect this to work
>-> reliably
>-> without at least hacking Quixote's Publisher.__init__ and
>-> get_publisher()
>-> to maintain a separate publisher for each thread.
>
>You are correct, suh.
>
>This is a bit of dilemma.  Quixote apps aren't thread-safe out of the
>box,
>
>       http://issola.caltech.edu/~t/q2-doc/multi-threaded.html
>
>

I forgot about the thread safety problem.  But the standalone mode is
just meant as a quick demo; production users will have their own
favorite server to plug the QWIP object into.  So maybe the answer is to
make a version of the simple server that understands WSGI.  I'll look
into that.

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?

I call a create_publisher function like all Quixote servers do, so I
can't provide an alternate Publisher class without grafting a mixin in
after the object is made.  The user shouldn't have to write two
create_publishers, they should be able to write one that works
everywhere.  I could call create_publisher with a multithreaded argument
but existing functions would crash.

I'm not sure how all this will work with a middlewareized publisher,
which may require setting quixote._publisher to a fake publisher that
directs get_*() calls into the middleware.

>Note the PEP comment,
>
>       http://www.python.org/peps/pep-0333.html#thread-support
>
>so maybe WSGIUtils should be changed to allow this?
>
>

That may be optimistic on the PEP's part.  Threaded servers may require
significant retrofitting to disable parallel processing that may already
have been initialized.

>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.
reply