Titus Brown wrote:

>-> 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 ;).
>
>

The developers don't have to do the thread testing themselves.  They can
mark the feature as "experimental" and let interested users test it.
The main question is, would adding the code in multi-threaded.txt be
detrimental to single-threaded deployments.  I can't think of any reason
why.

#### test_threading.py
import sys, thread, time
lock = thread.allocate_lock()

def identify(prefix):
    lock.acquire()
    print prefix, thread.get_ident()
    sys.stdout.flush()
    lock.release()

identify("Before thread")
child_id = thread.start_new_thread(identify, ("In thread",) )
identify("Outside thread")
time.sleep(2) # Give child time to finish since there's no thread.join()
func.
####

This seems to work reliably and efficiently whether the child thread is
started or not.

What the lack of thread safety has done is discourage research into
threaded servers.  Until now the question has been academic since there
have been no Quixote-compatible threaded servers anyway, at least none
that were generally known.  So people like me who would have liked to
use a threaded server have just used the servers that exist rather than
(1) writing a server from scratch, (2) patching Quixote to use it, and
(3) debugging both of them.

David Binger wrote:
 > If you intend for this to work with earlier versions of the quixote
 > Publisher, though, are you convinced that there is a benefit of
 > having "is_thread_safe = False" on the quixote publisher class?
 > It seems like any python code should be assumed to be
 > not-thread-safe at least until someone studies it and describes
 > the conditions under which it may be treated as thread-safe.

Yes, but I'd say the responsibility is reversed.   Programmers should
document any non-thread-safe features in their code.  It's not so much
about threading as about compatibility.  One should document any known
incompatibilities the program has.  With WSGI this is especially
important because people will want to plug any WSGI-compatible component
into any other.  So if I have a bug with one server, for instance, I can
plug in another one.   If Quixote were intrinsically thread-unsafe, I'd
just make QWIP unconditionally raise an exception for multithreaded
servers.  But here we have a case where the publisher might be safe or
might not, and inquiring minds want to know.  .is_thread_safe provides
an obvious way to specify this.  If the flag exists, implementors of
safe publishers will override it.  Otherwise they may start inventing
other flags or not specifying it at all, or maybe mention it in
paragraph 16 of appendix E.

But I'd still argue that making the default Publisher thread-safe would
be ideal.  There used to be Publisher and SessionPublisher and then they
were merged, why not do the same with ThreadedPublisher?  Or at least
put it in the publish module so it will get some widespread use and
testing, and so people will tend to use that class rather than writing
their own private class.