Tornado as your server: WSGI container lands in Tornado

http://github.com/facebook/tornado/commit/8ca616088cfb26ff19fcc6f359d654fef905b8da

by masklinn • 17 years ago

29 6 17 years ago

github.com

jacquesm2• 17 years ago

please take note of this very important caveat:

> Since no asynchronous methods are available for WSGI applications, the

> httpclient and auth modules are both not available for WSGI applications.

The reason for the omission of the httpclient because of the inability of a WSGI application to set up and retrieve resources without blocking the whole process is clear enough, but I fail to see how the authentication module should suffer from this as well.

n8agrin• 17 years ago

A brief glance at the code shows that the auth module is omitted because certain classes in the lib (OAuth, OpenID, etc) use the httpclient, specifically the class httpclient.AsyncHTTPClient.

jacquesm2• 17 years ago

Ah, so actually it is just the httpclient that causes all this. It shouldn't be too hard to come up with a version of that lib that uses some local authentication method though.

PhilChristensen• 17 years ago

okay, i give up.

explain to me how it's possible to run any significant WSGI app inside this container. wouldn't any long-running request monopolize the whole server?

i don't have a lot of exposure to other WSGI apps besides my own, but I always use synchronous, blocking development techniques when building them, including blocking database calls.

kingkilr• 17 years ago

That's correct. This is why most WSGI people (such as Graham Dumpleton, author of mod_wsgi) are opposed to adding any sort of async stuff to the WSGI spec as well.

dlsspy• 17 years ago

twisted does it by using deferToThread (so the call sits in a thread pool and the reactor doesn't block).

I suppose they just need their twisted loop clone thing to implement deferToThread now.

Tornado as your server: WSGI container lands in Tornado

Related Stories