-
-
Notifications
You must be signed in to change notification settings - Fork 503
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync version of broadcast #1466
Comments
Yes, that would be nice. As long as it doesn't exist in the library, I'd recommend against your first option. Your second option can be implemented quite easily with a ThreadPoolExecutor that will handle the queuing and consuming for you. Given enough threads and a short enough timeout on If you have 5000 connections you shouldn't be using the thread-based implementation in the first place :-) |
Marking as a potential improvement. |
The library includes a
broadcast
utility, with detailed documentation and motivation here.However, today that utility only works with the asyncio API of WebSockets.
That leaves users of the sync API with two possibilities, if they want to broadcast a message without risk of blocking the thread if some client's buffer is full:
broadcast
by accessing directly thesocket
and the sans-IO API to set the sockets to be non-blocking during the broadcast. (tricky!)broadcast
by the way of application-level queues, and per-client threads consuming from the queues (runtime and implementation overhead)It would be nice if the sync API of this library included a ready-made broadcast utility.
The text was updated successfully, but these errors were encountered: