4

UPDATE: after much laboring with Py3, including writing my own asynchronous webserver (following a presentation given by Dave Beazley), i finally dumped Python (and a huge stack of my code )-: in favor of CoffeeScript running on NodeJS. Check it out: GitHub (where you'll find like 95% of all interesting code these days), npm (package manager that couldn't be any user friendly; good riddance, easy_install, you never lived up to your name), an insanely huge repository of modules (with tons of new stuff being published virtually 24/7), a huge and vibrant community, out-of-the-box asynchronous HTTP and filehandling..., all that (thanks to V8) at one third the speed of light — what's not to like? read more propaganda: "The future of Scripting" (slide hosting courtesy SpreeWebdesign).

I am looking for a way to serve HTTP (and do HTTP requests) in an asynchronous, non-blocking fashion. This seems to be hard to do when you’ve decided on Stackless Python 3.1 (also see here for docs) as i did.

There are some basic examples, like the pretty informative and detailed article How To Use Linux epoll with Python, and there is a a Google code project named stacklessexamples which contains some valuable information (but no Python 3.x compatible code).

So, after many days of doing research on the web and trying to put together the pieces i’ve found so far: does anyone know of a fairly usable asynchronous HTTP library? It doesn’t have to be WSGI-compliant (I am not interested in that).

The server part should be able to serve multiple non-blocking HTTP requests (and possibly do the basics of HTTP header processing); the HTTP client part should be able to retrieve, in a non-blocking way, web content via HTTP requests (also doing basic header processing, but no fancy stuff like authorization or so).

My research so far has shown me that non-blocking HTTP

  1. is the only way that makes sense in a stackless, cooperatively scheduled environment;

  2. is feasible in Stackless Python 3 by virtue of the standard library’s select epoll (introduced in Py2.6; some solutions prefer libevent, but that means another hurdle as the pyevent project seems to have stopped developing at Py2.5);

  3. is sadly still not a household item, with most people relying on blocking HTTP.

The way it looks like now, i would have to learn the basics of socket programming and roll my own HTTP server/client library. I still shy away from that task as i have very little background in that area and am bound to ‘repeat history’ that way.

I would be very happy about any relevant pointers. I prefer very much solutions that make use of select.epoll; i seem to remember it is much more scalable that the older asyncore (but maybe someone has more precise data on this). As a minimum requirement, solutions should run on Ubuntu 9.10.

flow
  • 3,624
  • 36
  • 48
  • Re your point 3, asynchronous (AKA event-driven) HTTP (and other networking) is really very popular in super-scalable situations where it's needed -- beyond asyncore, you have Twisted, Tornado, and, beyond Python, lighttpd 1.5 (with asyncio), nginx, Erlang, etc; it's just rarely used together with stackless Python, and especially the new, still not broadly adopted version 3 thereof. – Alex Martelli Mar 03 '10 at 16:06
  • this is very much my feeling, that asynchronous HTTP is gaining traction, and for a good reason. Wouldn’t it be lovely if there was a working high-performance out-of-the-box solution in the standard library? Maybe we could [rant]throw out the likes of `aifc` and `sndhdr` and[/rant] use that floor space for more useful things? – flow Mar 03 '10 at 16:30
  • why python3.1? Why stackless? Wouldn't you be satisfied with a good 2.6 Cpython solution? Why this artificial restriction? – nosklo Mar 03 '10 at 21:41
  • 1
    far from feeling this restriction is artificial, i believe that moving from Py2.x to Py3.x is the way to go. i still have a lot of my software running under 2.x, but am in the middle of a major re-write. doing this within the 2.x series seems artificial, as those versions have (probably) reached the end of their development lifetime. i am fully aware that many maintainers of software for python are loathe to make the move; but then, an uncounted number of projects have somewhere in the past already ceased development, and will be obsolete within a few years. to go py3 is to go with the ~flow! – flow Mar 03 '10 at 21:56
  • You are mixing 2 separate issues here: moving to python 3 and using stackless or any other high perf HTTP. Do yourself a favor treat the separately. – GabiMe May 30 '11 at 10:19
  • to me that sounds like being replied "you're mixing issues here" when asking for "a cup of coffee" — that's asking for a container and a beverage, after all. this is not about migrating to Py3, this is about using Py3 — and why not? Py3 was released end of 2008, now we're at the beginning of 2012. the final 2.x version was published two years ago, which means Py2 is bound to go away. that said, i've moved to NodeJS and CoffeeScript last summer (2010), and after a decade of programming with Python, i don't look back. Python is starting to look dusty to me. – flow Jan 19 '12 at 16:08

2 Answers2

0

I know this is like resurrecting the dead (and flow has probably long since solved his problem), but for completeness stackless is available for 3.1.3:

For information on implementing a HTTP server using stacklesssocket:

Dale Reidy
  • 1,189
  • 9
  • 22
  • thx anyway! in fact i now have built an asynchronous http server following david beazley's suggestions (http://www.slideshare.net/dabeaz/a-curious-course-on-coroutines-and-concurrency-5286140). it's sort of experimental and actually uses generators for coroutines, not stackless python. it is still difficult to find tested and proven asynchronous http servers for python, let alone python 3. – flow Jan 27 '11 at 23:39
0

Non blocking HTTP case is very well handled with twisted, what is does is creating a series of callbacks, and registering those callbacks with deferred. Twisted documentation is worth checking out. Stackless uses microthreads but twisted is coding the entire web framework using fragment by fragment non bloking code chained with callbacks, errbacks and deferreds running is a main reactor loop over a single thread. Think this should the Async HTTP thing better.

pranjal
  • 692
  • 1
  • 6
  • 19
  • 1
    not ten horses could make me touch that inscrutable big ball of wibbly-wobbly ... er ... stuff that is called twisted (they knew what they wanted, they did it, and they gave their kid the right name). hey grab NodeJS and you get an asynchronous web server in under ten lines of code! this is 2012, so good-bye to stackless, i really loved you but i had to move out of town. also i'm sad to say that twisted doesn't work with Py3 (as of Jan, 2012), and acc. to http://twistedmatrix.com/trac/milestone/Python-3.x and http://stackoverflow.com/a/214601/256361 it may take some time yet. 2022 anyone? – flow Jan 19 '12 at 17:01