#36863: Under WSGI, multiple calls to asgiref.sync.async_to_sync within the same
request do not share the same event loop.
-------------------------------------+-------------------------------------
Reporter: Mykhailo Havelia | Owner: Vishy
Type: | Algo
Cleanup/optimization | Status: new
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async, wsgi | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mykhailo Havelia):
Replying to [comment:16 Jacob Walls]:
Hi Jacob,
First of all, thanks so much for your really quick response 🙂
> - the django-async-backend can be advanced and tested on ASGI-only
setups ...
> - otherwise you can use a reverse proxy to direct traffic between ...
Of course, we can do that 😔 I'll just go ahead without it for now.
> the reference I found to DEP 0009 is indeed out of date, we should not
draw the conclusion from that that it's accepted to add a single event
loop for WSGI handler
That makes sense. Basically, Django lets us run sync code inside async
temporarily (like a bridge while async backends aren't ready), but we
can't run a fully async app on a sync server.
- Django forces it in some places, wrapping any async view with
`async_to_sync` for some reason and middlewares too.
- Even some newer features, like task backends, require it.
{{{
def call(self, *args, **kwargs):
if iscoroutinefunction(self.func):
return async_to_sync(self.func)(*args, **kwargs)
return self.func(*args, **kwargs)
}}}
Because of this, we can't properly close async connections at the end of a
request, which could lead to connection leaks at best.
- And to make things more confusing, Django documentation sometimes gives
the impression that this is fine 😁
> Async views will still work under WSGI, but with performance penalties,
and without the ability to have efficient long-running requests.
> Under a WSGI server, async views will run in their own, one-off event
loop. This means you can use async features, like concurrent async HTTP
requests, without any issues, but you will not get the benefits of an
async stack.
> In both ASGI and WSGI mode, you can still safely use asynchronous
support to run code concurrently rather than serially. This is especially
handy when dealing with external APIs or data stores.
Based on that, I have a couple of questions:
1. Would it be okay if I prepare an MR to fix the documentation and add
some details about Daphne?
2. Can I open a ticket to discuss removing support for async views and
middlewares under WSGI?
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:17>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019c1f18687e-802ad6a4-9c90-466a-bc93-06f2876e1dff-000000%40eu-central-1.amazonses.com.
