[Django] #36863: Under WSGI, multiple calls to asgiref.sync.async_to_sync within the same request do not share the same event loop.

[Django]

#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 | Type: Bug
Status: new | Component: HTTP
| handling
Version: 6.0 | Severity: Normal
Keywords: async, wsgi | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Each call creates a new thread with its own event loop. This commonly
happens in middlewares and signals, causing a single request to spawn
multiple threads and event loops, which is unnecessary and prevents reuse
of async resources.

This could be addressed by introducing a per-request async context, for
example as shown in this draft implementation:
https://github.com/Arfey/django/pull/5/changes
--
Ticket URL: <https://code.djangoproject.com/ticket/36863>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#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: (none)

Type: Bug | Status: new
Component: HTTP handling | Version: 6.0

Severity: Normal | Resolution:

Keywords: async, wsgi | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

----------------------------------+--------------------------------------
Changes (by Flavio Curella):

* cc: Flavio Curella (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:1>

[Django]

#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: (none)
Type: Bug | Status: new
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async, wsgi | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------

Comment (by Kundan Yadav):

hey can i work on this issue ?
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:2>

[Django]

#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: (none)
Type: Bug | Status: new
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async, wsgi | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------

Comment (by Jacob Walls):

Thanks, but you should wait for it to be accepted first.
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:3>

[Django]

#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: (none)
Type: Bug | Status: new
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async, wsgi | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------

Comment (by Vishy Algo):

With asgiref >= 3.10, we can leverage AsyncSingleThreadContext to enforce
a persistent execution context for the entire request lifecycle.

I suggest wrapping the {{{ WSGIHandler.__call__ }}} logic in this context.
Crucially, because the WSGI response iteration often outlives the {{{
__call__ }}} stack frame (e.g. StreamingHttpResponse), we cannot use a
simple with block or decorator. Instead, we must manually manage the
context's lifecycle and attach the cleanup logic to response.close().

I’ve verified this behavior with a test asserting that the thread is
successfully reused across calls.

{{{#!diff
diff --git a/django/core/handlers/wsgi.py b/django/core/handlers/wsgi.py
index aab9fe0c49..d531c6a564 100644
--- a/django/core/handlers/wsgi.py
+++ b/django/core/handlers/wsgi.py
@@ -118,30 +118,45 @@ class WSGIHandler(base.BaseHandler):
self.load_middleware()

def __call__(self, environ, start_response):
- set_script_prefix(get_script_name(environ))
- signals.request_started.send(sender=self.__class__,
environ=environ)
- request = self.request_class(environ)
- response = self.get_response(request)
-
- response._handler_class = self.__class__
-
- status = "%d %s" % (response.status_code, response.reason_phrase)
- response_headers = [
- *response.items(),
- *(("Set-Cookie", c.OutputString()) for c in
response.cookies.values()),
- ]
- start_response(status, response_headers)
- if getattr(response, "file_to_stream", None) is not None and
environ.get(
- "wsgi.file_wrapper"
- ):
- # If `wsgi.file_wrapper` is used the WSGI server does not
call
- # .close on the response, but on the file wrapper. Patch it
to use
- # response.close instead which takes care of closing all
files.
- response.file_to_stream.close = response.close
- response = environ["wsgi.file_wrapper"](
- response.file_to_stream, response.block_size
- )
- return response
+ async_context = AsyncSingleThreadContext()
+ async_context.__enter__()
+ try:
+ set_script_prefix(get_script_name(environ))
+ signals.request_started.send(sender=self.__class__,
environ=environ)
+ request = self.request_class(environ)
+ response = self.get_response(request)
+
+ response._handler_class = self.__class__
+
+ status = "%d %s" % (response.status_code,
response.reason_phrase)
+ response_headers = [
+ *response.items(),
+ *(("Set-Cookie", c.OutputString()) for c in
response.cookies.values()),
+ ]
+ start_response(status, response_headers)
+
+ original_close = response.close
+
+ def close():
+ try:
+ original_close()
+ finally:
+ async_context.__exit__(None, None, None)
+
+ if getattr(response, "file_to_stream", None) is not None and
environ.get(
+ "wsgi.file_wrapper"
+ ):
+ # If `wsgi.file_wrapper` is used the WSGI server does not
call
+ # .close on the response, but on the file wrapper. Patch
it to use
+ # response.close instead which takes care of closing all
files.
+ response.file_to_stream.close = response.close
+ response = environ["wsgi.file_wrapper"](
+ response.file_to_stream, response.block_size
+ )
+ return response
+ except Exception:
+ async_context.__exit__(None, None, None)
+ raise
}}}


{{{#!python
def test_async_context_reuse(self):
"""
Multiple calls to async_to_sync within a single request share the
same thread and event loop via AsyncSingleThreadContext.
"""
async def get_thread_ident():
return threading.get_ident()

class ProbingHandler(WSGIHandler):
def __init__(self):
pass

def get_response(self, request):
t1 = async_to_sync(get_thread_ident)()
t2 = async_to_sync(get_thread_ident)()
return HttpResponse(f"{t1}|{t2}")

app = ProbingHandler()
environ = self.request_factory._base_environ(PATH_INFO="/")

def start_response(status, headers):
pass

response = app(environ, start_response)
content = b"".join(response).decode("utf-8")
t1, t2 = content.split("|")

self.assertEqual(
t1, t2,
f"Failed: async_to_sync spawned new threads ({t1} vs {t2}).
Context was not reused."
)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:4>

[Django]

#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 Algo
Type: Bug | Status: assigned

Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async, wsgi | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------

Changes (by Vishy Algo):

* owner: (none) => Vishy Algo
* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:5>

[Django]

#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 Algo
Type: Bug | Status: assigned
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async, wsgi | Triage Stage: Unreviewed
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:4 Vishy Algo]:

Okay. I’m going to add tests for my MR and then submit it for code review.
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:6>

[Django]

#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 Algo
Type: Bug | Status: assigned
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async, wsgi | Triage Stage: Unreviewed
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:4 Vishy Algo]:

I prepared an MR, but it seems it's not sufficient:
https://github.com/django/django/pull/20552. I added a test that compares
not just the thread, but the event loop as well, and the event loop isn't
the same. asgiref uses the same thread, but it starts a new event loop for
each function via asyncio.run
(https://github.com/django/asgiref/blob/main/asgiref/sync.py#L314).
I could try creating a loop myself and run each function via
loop.run_until_complete, but that would require some additional
investigation to see if it's feasible.

What do you think?
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:7>

[Django]

#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 Algo
Type: Bug | Status: assigned
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async, wsgi | Triage Stage: Unreviewed
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:3 Jacob Walls]:

I've added an MR with changes to asgiref that should help with sharing the
same event loop. There are still some issues on lower Python versions, but
the overall approach can already be reviewed 😌
https://github.com/django/asgiref/pull/542
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:8>

[Django]

#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: closed

Component: HTTP handling | Version: 6.0

Severity: Normal | Resolution: needsinfo

Keywords: async, wsgi | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

-------------------------------------+-------------------------------------
Changes (by Jacob Walls):

* resolution: => needsinfo
* status: assigned => closed
* type: Bug => Cleanup/optimization

Comment:

Thanks Mykhalio. Can you help me quantify the performance impact? I'd like
to know the upside for async users as well as the downside for WGSI users
who have no async middleware or signals.

I notice your draft PR for the `WSGIHandler` has a nested function. We're
starting to see tickets along the lines of "X created nested functions
that take a gc pass to free". My understanding is that this is much less
of a worry on Python 3.14 now that we have incremental gc, but still. I
just want to know what WSGI-only users are paying.

Happy for you to reopen for another look with those details in hand, but
full disclosure we're going to need a few more +1s from knowledgable
parties to accept.
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:9>

[Django]

#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: closed
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution: needsinfo
Keywords: async, wsgi | Triage Stage:
| Unreviewed
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:9 Jacob Walls]:

Hey. Thanks for response 😌


**Async upside**

Right now async views under the dev server go through `async_to_sync`,
which runs them in a separate event loop. That breaks loop-bound resources
(DB clients, HTTP clients, etc.) and we see errors like "event loop is
closed". This change keeps async work in a consistent per-request loop, so
async code behaves like it does under ASGI. The win is mainly correctness
and lifecycle safety, not raw speed.


**Cost for WSGI-only users**

You're right that the current approach introduces a reference cycle by
wrapping `response.close`. That means the response object is reclaimed on
a GC pass instead of immediately via refcounting.

{{{
gc.disable()
gc.collect()

response = application(environ, start_response)
ref_response = weakref.ref(response)
response.close()
del response

print("before", ref_response() is None)
gc.collect()
print("after", ref_response() is None)
}}}
Output:
{{{
before False
after True
}}}

**Mitigation**

We can avoid the cycle entirely by moving the cleanup hook into the
response layer (registering extra closers instead of wrapping close). That
keeps refcount-based cleanup and makes the WSGI path effectively neutral.

{{{
class HttpResponseBase:
def close(self):
...
signals.request_finished.send(sender=self._handler_class)

for closer in self._after_resource_closers:
try:
closer()
except Exception:
pass

self._after_resource_closers.clear()
}}}

{{{
response._add_after_resorce_closer(cleanup_stack.close)
}}}

What do you think? 🙂
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:10>

[Django]

#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:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Mykhailo Havelia):

* resolution: needsinfo =>
* status: closed => new

--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:11>

[Django]

#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:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Jacob Walls):

At a glance that cleanup strategy seems more attractive in order to
unclutter the `WSGIHandler`, but we can defer that to PR review.

I think I understand the ask here; I'm just wondering why it was never
designed this way. Our [https://docs.djangoproject.com/en/6.0/topics/async
/#async-views docs] read:

> 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.

So, am I to understand that there are, in fact, "issues" here, issues that
are not resolvable by, "just use an ASGI stack"?
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:12>

[Django]

#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:
| Unreviewed
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:12 Jacob Walls]:

> At a glance that cleanup strategy seems more attractive

Nice, glad that direction makes sense. I'll put together an MR with tests
so we can try it out properly.

> So, am I to understand that there are, in fact, "issues" here, issues
that are not resolvable by, "just use an ASGI stack"?

I might be misunderstanding the question a bit 🙂 It does work correctly
under ASGI, yes. But I'd still consider this an issue, because the
behavior differs depending on the server stack, and that can lead to
subtle lifecycle problems especially in development where people commonly
use WSGI.

I've gotta fix this for async backends. https://github.com/Arfey/django-
async-backend/issues/4#issuecomment-3749548648
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:13>

[Django]

#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
-------------------------------------+-------------------------------------

Changes (by Jacob Walls):

* stage: Unreviewed => Someday/Maybe

Comment:

I want to help you advance the django-async-backend, but I'm not certain
that it needs to support WSGI right now in order to advance. I'll leave a
comment on the [https://github.com/django/new-features/issues/7 new-
features repo issue] that tracks that work to get more input. I could be
not understanding the intended audience of testers. Can't we test this
with `daphne`'s runserver?

About why it was designed this way, I did find a reference in the
[https://github.com/django/deps/blob/main/accepted/0009-async.rst#high-
level-summary async DEP] about the intended final design:

> WSGI mode will run a single event loop around each Django call to make
the async handling layer compatible with a synchronous server.

So that supports the idea that we would eventually get around to your
proposal, but since DEP 0009 there have been other conversations to the
effect of, "aren't we basically done except for the async database
backend." And if that's ASGI-only for now, that might be enough?

I can check my understanding with the Steering Council early next week.
Setting Someday/Maybe until then.
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:14>

[Django]

#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:14 Jacob Walls]:

> I want to help you advance the django-async-backend

I really appreciate that, thank you so much ☺️

> I could be not understanding the intended audience of testers. Can't we
test this with daphne's runserver?

We have a fairly large Django project that was set up long before async
support existed. Part of it is now async (separate API endpoints), but a
big portion is still fully sync. For development, we run everything
through a single server so the whole system works together in one place.

Technically, yes. I could run async parts with Uvicorn/Gunicorn and keep
the rest elsewhere. But then we'd need:
- two dev servers
- plus something to sit in front and combine them
- and both servers would need restarting on code changes

That makes the dev setup more complex and increases the barrier for other
teams. Just running the backend requires extra infrastructure and
configuration, which grows over time.

A concrete example is async Redis usage. It works fine under ASGI, but
under WSGI we hit real limitations:
- connections can't be shared properly across requests
- we can't reliably close them at the end of the request because the
expected async lifecycle and signals don't behave the same way

ASGI only sounds easy, but with a unified dev setup this is exactly where
problems show up.

> So that supports the idea that we would eventually get around to your
proposal

DEP 0009 is 6 years old already 😅 still waiting. a bit ironic.

> but since DEP 0009 there have been other conversations to the effect of,
"aren't we basically done except for the async database backend."

I kind of wish that were true 🙂 From my side, there's still a lot of work
left

> And if that's ASGI-only for now, that might be enough?

In practice, a lot of internal Django code still ends up going through
async - sync bridges. People wrap things in `sync_to_async` and assume
they're writing fully async code. This is a really remarkable thread on
this topic https://forum.djangoproject.com/t/asynctestclient/43841😅

> I can check my understanding with the Steering Council early next week.
Setting Someday/Maybe until then.

thank you so much 😌

btw: If you need any more info, just message me anytime.
--
Ticket URL: <https://code.djangoproject.com/ticket/36863#comment:15>