> I haven't tried your test yet, but one thought: twisted_http
> doesn't support
> Stream objects properly.  The Medusa server does support them,
> returning an
> object that calls the Stream's .next() method over and over, but
> twisted_http reads all the contents of the Stream into a string
> and returns
> the string.  I could imagine this being responsible -- Twisted
> sends all the
> data for one image before servicing the next.

Yeah,  I've noticed that, and that's actually at the core of what I'm
working on to try to fix this.  I'm taking the output from quixote, and
pushing it into a producer-ish thing that twisted seems to like.  What I
have right now isn't very elegant, as I take the output of quixote (if it's
a stream, I still convert it to a string) and then push it into my 'Buffer'
object (the producer-ish) thing, and then hand that off to twisted.  It's
not very memory effecient (for example, if you're returning a large
StaticFile, it'll pull the whole thing into RAM), but it seems fast in my
tests so far.  I'll be looking to get things set up better before I submit a
patch.

At this point, I'm still trying to get my head wrapped around the problem.
It's been really weird, troubleshooting this.  With the 'standard' quixote /
twisted thing running, the select call in twisted's I/O loop will block for
a short time (1-2 tenths of a second) even when you would expect it to
return immediately (because there's input ready).  Well, I would expect it
to, anyway.

Jason