#37177: Performance issue in Async Middleware handling.
--------------------------------+---------------------------------------
Reporter: Carlton Gibson | Owner: Jacob Walls
Type: Bug | Status: assigned
Component: HTTP handling | Version: 6.0
Severity: Normal | Resolution:
Keywords: async | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------+---------------------------------------
Changes (by Jacob Walls):
* has_patch: 0 => 1
Comment:
Replying to [comment:16 Mykhailo Havelia]:
> I was worried about two things.
>
> - Backwards compatibility, for people who extend default Django
middlewares and rely on async_capable and/or __acall__.
> - People who don't want to use threads but still want to use at least
the default CPU-bound Django middlewares.
>
> To avoid breaking backwards compatibility, I couldn't find a better
solution than providing dedicated async middlewares. Anyway, we can split
it and do it step by step
>
>
You're right to consider that, but I think the intended design was that
users wouldn't have to swap in async-only middlewares.
On point one, we're talking about asking users who have subclassed the
concrete middlewares and implemented their own `__acall__()` to await
`get_response()`, now having to set `async_capable = True`. Backward
compatibility protections are a bit weaker when you're subclassing.
On point two, by not deprecating `MiddlewareMixin.__acall__()` entirely,
we've left it so the users who don't mind the context switches can get the
prior behavior by again, just setting one attribute.
Appreciate any reviews on [https://github.com/django/django/pull/21523
PR]! It does the most minimal thing for now, i.e. "Manually mark
(affected) built in middleware as async_capable = False".
Of course, it is not essential to push this into Django 6.1 next week, but
I wanted to at least present the option.
--
Ticket URL: <https://code.djangoproject.com/ticket/37177#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/0107019ee2003f44-d4c6f64a-8662-4cc6-a952-e9ea8627fc4d-000000%40eu-central-1.amazonses.com.