some thoughts on handling both non-blocking and blocking requests efficiently

[zhibin]

Hi,

I am new to tornado. Here are some of my thoughts:

After a HttpConnection read_until "\r\n\r\n", a HttpRequest is
created, which is
then handled by class Application. In Application.__call__, the
handler for
the HttpRequest is called synchronously.

Here, how about put that request into a thread pool?

This way, a reqest can still be handled asynchorously in worker thread
if possible,
but when you have to use blocking db calls, the server will behave
like any other
multi-threaded blocking web servers.

Benefits:
since both non-blocking and blocking requests can be handled in one
server,
I can use the auth-mixins asynchorounsly, even serve a chat room
asynchorounsly,
and still can get/save information from/to database in other web
pages.

Potential Problems:
thread-safety?

I am not sure whether or not these thoughts are feasible, anyone
interested in it?

Thanks,

[Ben Darnell]

You could do this (and it's the way I'd design a tornado-like
framework for a language like java or c++), but I wouldn't recommend
it in most cases for python. The python GIL prevents you from making
full use of multiple cpus (which covers most servers these days) even
in a multi-threaded app, so you have to run multiple processes. Once
you're running multiple processes, you can easily just run a few more
as needed to fill in any utilization gaps that may be left by any
blocking database/memcache/etc calls you are doing. Multiple threads
in one process will be a little more efficient than running more
processes, but since thread-safety is never trivial it's unlikely to
be worth the effort. As long as your database operations are
reasonably efficient (properly indexed, etc), you don't need to worry
too much about doing blocking calls to the database in your
RequestHandlers.

-Ben