That sounds like a massive improvement and goes in line with the issues I've observed.
On Tuesday, March 28, 2017 at 3:51:20 AM UTC+2, Andrew Godwin wrote: > > Hi all, > > I wanted to ask your feedback on a proposed change I want to make to the > ASGI spec for channel layers. > > In particular, my goal is to make it so that Daphne only has to receive() > on a single channel at any time, massively simplifying the work it takes to > poll for new messages and the overhead that switching channel sets all the > time caused. > > The way I want to do this is to redefine process-local channels - those > with a ! in them - so that they are written like this: > > http.response.PROCESSID!LOCALID > > Then, change the semantics of receive() so that you only call > > channel_layer.receive(["http.response.PROCESSID!"]) > > And this then receives any message sent to any channel with that prefix. > The channel name returned from receive() is still the full name as sent by > the client; it's basically acting as a very limited wildcard. > > This will allow Daphne (and any other server) to listen on just a single > process-local channel, with a random part made by the process at boot (e.g. > "http.response.A34GF3!"), and then internally dispatch messages as they > come in to the appropriate client socket. It also means that the client API > - the one seen by end-developers and the Channels library itself - does not > change at all, as the reply_channel can still be set to something like > "http.response.A34GF3!K89C3", and everything will flow correctly. > > It's better than full wildcard support as that may be very inefficient to > implement depending on the server; the limitation means that > implementations can just deliver into queues based on the non-local part > and stuff the "full" channel name into the message storage area, and unpack > it again on receive. > > The potential benefits to efficiency are hard to understate; the current > definition of process-local channels was meant to allow channel layers to > do something like this internally but it still needed server code to swap > out the list of things it was listening on every receive() call. By > removing this abstraction, servers can be written with a single tight loop > around a fixed set of channel names, and we can block way more efficiently > on servers like Redis. > > I want to know if anyone has any feedback on this, especially from the > "potential problems" department; if not, I'm going to try and get this out > before DjangoCon Europe. > > Thanks! > > Andrew > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/451e2867-372b-4d54-9ace-9ac784bb5fae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
