multitask http server (single-process multi-connection HTTP server)

Tim Wintle tim.wintle at teamrubber.com
Mon Jul 12 21:30:38 EDT 2010


On Mon, 2010-07-12 at 23:28 +0000, Luke Kenneth Casson Leighton wrote:
> On Mon, Jul 12, 2010 at 10:13 PM, geremy condra <debatem1 at gmail.com> wrote:
> > On Mon, Jul 12, 2010 at 4:59 PM, lkcl <luke.leighton at gmail.com> wrote:
> >> there probably exist perfectly good web frameworks that are capable of
> >> doing this sort of thing: i feel certain that twisted is one of them.
> >> however, the original author of rtmplite decided to rip twisted out
> >> and to use multitask.py and i'm one of those strange people that also
> >> likes the idea of using 900 lines of awesome elegant code rather than
> >> tens of thousands of constantly-moving-target.

have you seen nagare:
http://www.nagare.org/

I've not used it - but from my understanding it might be what you're
looking for (for the http part at least).

> i hate to think how this would be done using any of the standard
> MixIns.  even if you wrote a special MixIn which did single-instance
> socket handling, you couldn't use it because the BaseHTTPHandler
> doesn't "cooperate", it has a while True loop on serving connections
> until they're closed.

I started working on something like this once (but I still had threads)
- afraid I can't find the code with it in right now. I think it was
similar to what you're doing:

at least 2 threads - one accepts requests, the other deals with them.

 * overload BaseHTTPServer.process_request so it just adds connections
to a queue.

 * worker threads fetch connections from the queue and starts working on
them. when they want to give up control they raise an exception to
bubble back up, and the connection is re-added to the queue along with
any persistent data.

I seem to remember the annoying bit being having to override
SocketServer.finish_request to use an existing handler.

- you can fairly easily limit that to process a single session at a time
with a shared dictionary or similar.


The reason I was doing it was for work that was cached for a short time,
but took a while on cache misses - If I noticed that another thread was
currently updating the cached version then I raised an exception. (I had
code that unlocked the gil, so multi-threaded made sense)


Tim







More information about the Python-list mailing list