> > Sure. You probably would want to escape from wsgi for the couple of urls > in your application that really need to be async, while writing the > traditional parts traditionally. >
This is where I think Brubeck would really shine. It works entirely around gevent's natural async mechanism while keeping all the code looking sync, just as gevent promises. Pairing up uWSGI with gevent forces code to look like this: http://projects.unbit.it/uwsgi/wiki/Gevent - Which means the user is explicitly calling yield to context switch with WSGI. This means you actually have both implicit and explicit context switching. One is often confusing enough. > You can also do pretty well with wsgi and greenlets (which iirc is how > mongrel2 is written internally - asynchronous code written in a synchronous > style). > You can do well, but it's still far from optimal by nature of being bound to WSGI. I think I see where you're going by comparing the internal design of mongrel2 to wsgi+greenlets, but it's not accurate. The main reason is that Mongrel2's eventloop doesn't have any requirements on the order things are handled. For example, Mongrel2 can send a message to a backend handler that won't respond for a minute. While it waits, it can handle any other requests coming in because it's just going to send the messages to the zmq socket as they come in. By nature of having an external system decide when to respond, it is essentially forced to be async by nature. WSGI is not as flexible. I realize it probably feels like I'm nitpicking. I believe these details are important and worth getting right. Especially for users of Mongrel2. > > On Jun 24, 2012, at 9:39 PM, James Dennis <[email protected]> wrote: > > It's not asynchronous. WSGI cannot properly do asynchronous anything. It > is a straight-line of requests that must be handled in the same order > they're submitted. Thus, people have to write special code for long-polling > or websockets rather than work through existing systems. > > > On Sun, Jun 24, 2012 at 9:28 PM, Daniel Holth <[email protected]> wrote: > >> Uwsgi is useful because it is provides a complete platform for writing >> clustered web applications, including process management, spooling, and too >> many other things to mention. Great to see it working better with the >> asynchronous zeromq power of mongrel2. >> >> Daniel Holth >> > >
