On Sun, Jul 21, 2013 at 11:39 AM, Juan Luis Boya <ntr...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
