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

Reply via email to