Andrew Godwin

Hm, yeah, the extra complexity for such a small performance gain does give me a little pause. If there's another convincing reason to add it, like the connections, that might...

Yes, this is going to need an ASGI application (probably a consumer but might have to be lower-level) that does the de/re-multiplexing itself and then manages a suite of other...

The whole principle of the new ASGI design is turtles all the way down - that is, a demultiplexer should take any valid ASGI application as its demultiplexing endpoints. Otherwise...

`await_many_dispatch` will be the wrong model - there are other ways of making sure child coroutines close when their parent does. The reason the routers don't need this is that...

No, there's no need to "gather" loops, everything is being awaited (including `await_many_dispatch`) so it will all just run. Your previous comment's conclusion, that `await_many_dispatch` needs its own loop, is...

This is probably not going to happen unless someone else works on it - I don't have the time any more.

It may be essential, but it still has to be written by someone - at this point, I'm starting to focus my efforts more on Django async so unless we...

Multiplexing was never about the underlying protocol or support - the sticking point for me has always been that it needs a lot of client-side code and a good specification...

It appears this would happen if you somehow tried to accept or reject before you got a `websocket.connect` message (not sure how that's possible). I'll get a look at it...

It's worth trying it on an older asgiref version - let's say `3.1.4` - and see if it persists there. I had someone say they might have a potential problem...