Opened 4 years ago
Last modified 21 months ago
#32172 closed New feature
Adapt signals to allow async handlers — at Initial Version
Reported by: | Carlton Gibson | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Normal | Keywords: | async |
Cc: | Andrew Godwin, Jon Janzen | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Currently (circa 3.1) we have a couple of sync_to_async()
usages in the main line of `ASGIHandler.__call__()`, for the request life cycle signals:
await sync_to_async(signals.request_started.send, thread_sensitive=True)(sender=self.__class__, scope=scope)
Much as is done of the middleware, adapting to accept either synchronous or asynchronous middleware classes, it would be good to be able to push that sync_to_async()
call down into the send()
method, allowing signal handlers to be either sync (as now) or async coroutines.
This would give us the option of having a completely async request pathway, if we were to remove all synchronous middleware and signal handlers.
There will need to be some discussion, perhaps on a PR, or the Forum's Async category but opening this ticket to track efforts.