Well, in that case you'd have to invert the API to provide the channel layer with a callable for new messages and then run an event loop it controls, which is not going to work with async or most sync code. I think the best approach for something like that is putting the receive code in a separate thread (sync)/context (async) and then shuffling data over to the caller of receive() using queues etc.
Andrew On Wed, Jul 12, 2017 at 10:50 AM, Artem Malyshev <proofit...@gmail.com> wrote: > Hi, > > I know we discussed it in private. But I want to bring some ideas in > public. > > During asgi_rabbitmq implementation I notice that channel workers are > coupled to much to the polling of the channel layer. I want to try a > different approach when layer can decide on its own when the message > arrives in the channel without calling nonblocking receive constantly. > > Probably this design shift will feet 2.0 release. > > I'll try to implement it in the separate channels branch after PyCon > Russia 2017. > > > On Wednesday, July 12, 2017 at 2:25:27 PM UTC+3, Andrew Godwin wrote: >> >> Hi all, >> >> After recent threads on ASGI and similar problems ( >> https://groups.google.com/forum/#!topic/django-developers/_314PGl3Ao0), >> and my own introspection about where we are almost two years in, there are >> some changes I would like to make to the overall way ASGI/Channels works, >> both to make things easier to develop and to open the gates more for >> asyncio. >> >> I wrote up my thoughts as a blog post rather than my original plan to >> post it all here, so it's easier for people to read and refer back to: >> http://www.aeracode.org/2017/7/11/towards-channels-20/ >> >> As a summary, the key change is that the user's code would move to run >> in-process with Daphne (or whatever server), with the channel layer only >> servicing cross-process communication (e.g. event broadcast, user-to-user >> messaging, etc.). Most of the other changes stem from that decision, but >> there's almost no changes to channel layers themselves and minimal changes >> to the message format. >> >> Something I didn't mention in the blog post is that I think this also >> potentially opens up a way to start making parts of Django work >> asynchronously without having to do a full conversion, though that's a much >> bigger conversation I want to come back to once this work is mostly done. >> >> Thoughts/opinions would be much appreciated. >> >> 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > 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/78bcbbda-e609-42a3-bc6f- > 139a736a13a0%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/78bcbbda-e609-42a3-bc6f-139a736a13a0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/CAFwN1urFrdy2YoWmtp19X2FRsiWfEwXs1hjE_jz9fkW8GW%2BeWA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
