On Sun, Jul 21, 2013 at 11:39 AM, Juan Luis Boya <[email protected]> wrote: > * An asynchronous server may be attending many client connections at a time > for each worker thread. Concurrency is achieved within the thread using an > application specific dispatcher. In an asynchronous server, there is only > one blocking call accepted, which selects events from all connections. > Typically this call is select(), epoll() or kqueue() depending on the > system. **Other blocking calls must not be used because they would block the > entire server until they return, preventing all available processing for > other connections and thus killing server performance**. Therefore, > asynchronous programming impose additional restrictions to the programmer, > like:
this is mostly right; but python, being a high level language, leaves a lot of space to change things. greenlets, gevents and eventles take advantage of that, monkepatching several crucial parts of the standard library, making it asynchronous-friendly. in the end, reasonably good code becomes mostly good for an asynchronous sever. That's what happens when you run use gunicorn to run Django, which is a very popular option (and isn't bad at all). An asynchronous FCGI-WSGI tool could have a similar performance without any changes in Django. in fact, i still think that maybe (just maybe) the easiest would be to replace the HTTP parser in gunicorn with an FCGI one, keeping all the asynchronous structure and WSGI handling code. -- Javier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
