Sync version of broadcast

[Phlogistique]

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:

• Implement broadcast by accessing directly the socket and the sans-IO API to set the sockets to be non-blocking during the broadcast. (tricky!)
• Implement 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.

[aaugustin]

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 send(), you can guarantee that the operation will complete within a certain time frame e.g. if you have 50 connections, use 25 threads and a timeout at 5 seconds and you will finish within 10 seconds.

If you have 5000 connections you shouldn't be using the thread-based implementation in the first place :-)

[aaugustin]

Marking as a potential improvement.

[aaugustin]

I'm still somewhat skeptical that I want to provide this API at all.

For a small number connections, this will do the job:

for connection in connections:
    connection.send(message)

For a larger number of connections, the sync implementation isn't the right choice anyway.

[aaugustin]

To avoid the risk of blocking on one connection — a risk that exists only in high-throughput scenarios where asyncio is clearly a better choice — one can do this:

with concurrent.futures.ThreadPoolExecutor() as executor:
    for connection in connections:
        executor.submit(connection.send, message)

(which is the concrete implementation of my earlier suggestion to use ThreadPoolExecutor.

If I implement broadcast, this will probably be the core of the implementation, with error handling added.

[Phlogistique]

Blocking on one connection can happen even with a handful of connections. In my case, typically I will have a frozen/crashed client slowing down the server. As I don't want to create a thread every time I send a message, I settled for creating a thread and an application-level queue per client.