-> > On Thu, May 16, 2002 at 09:52:59AM -0400, Greg Ward wrote:
-> > > Not quite: there's still a global request object
-> >
-> > That could be attached to the publisher as well.
->
-> Doesn't solve the problem -- in a multi-threaded app, one publisher
-> could have many active requests.  It does reduce the number of globals,
-> though, and that's always a good thing.  The dict of thread-ids to
-> request objects should still work too.

If there are only two "globals" per request -- publisher and request --
then it's easy enough to use a thread identifier and dictionary, as
Greg said Zope does.  I'm just interested in seeing the number of places
that'd have to be modified go down...

I've been whinging about this multithreaded stuff for long enough that
I should just go ahead and do it, methinks ;).  Right now I have a global
thread lock...

For testing -- huh, not sure how to do that.  Any suggestions for a
simple test?  I could re-write ab in Python to keep 100 requests
coming in, each one with a distinct number attached to the URL, and
then ask my app to return that distinct number and assert that it's
the one I sent: i.e.

        http://myserver/q/5

returns

        5

If threads are getting confused, then the output of one will get attached
to the wrong URL.

Testing threaded apps is a bitch...

--titus