> On 06 May 2016, at 19:59, Donald Stufft <don...@stufft.io> wrote: > >> On May 6, 2016, at 1:45 PM, Andrew Godwin <and...@aeracode.org >> <mailto:and...@aeracode.org>> wrote: >> >> On Fri, May 6, 2016 at 9:11 AM, Donald Stufft <don...@stufft.io >> <mailto:don...@stufft.io>> wrote: >> >> So what sort of solution would I personally advocate had I the time or energy >> to do so? I would look towards what sort of pure Python API (like WSGI >> itself) >> could be added to allow a web server to pass websockets down into Django. >> >> I agree with the want to use things like HAProxy in the stack, but I think >> your idea of handling WebSockets natively in Django is far more difficult >> and fragile than Channels is, mostly due to our ten-year history of >> synchronous code. We would have to audit a large amount of the codebase to >> ensure it was all async compatible, not to mention drop python 2 suport, >> before we'd even get close. > > You don’t need to write it asynchronously. You need an async server but that > async server can execute synchronous code just fine using something like > deferToThread. That’s how twistd -n web —wsgi works today. It gets a request > and it deferToThread’s it to synchronous WSGI code.
Sure, this works for WSGI, but barring significant changes to Django, it doesn’t make it convenient to handle WSGI synchronously and WebSockets asynchronously with the same code base, let alone in the same process. Problems begin when you want a synchronous function and an asynchronous one to call the same function that does I/O, for example `get_session(session_id)` or `get_current_user(user_id)`. Every useful service serving authenticated users starts with these. If you’re very careful to never mix sync and async code, sure, it will work. It will be unforgiving, in the sense that it will be too easy to accidentally block the event loop handling the async bits. In the end, essentially, you end up writing two separate apps… and it's harder than writing actually them separately. That’s why I’m pessimistic about running everything on an event loop as long as we don’t have a way to guarantee that Django never blocks. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/126C7C2E-C14F-4E29-BCB6-539F72AF35DA%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
