Repository navigation
Compression #199
Description
Activity
Isn't this exactly what asyncio in Python helps with? Generally speaking, for each incoming WebSocket connection, you would start processing events on its own independent thread / event loop / etc. Without some code snippets, it is difficult to discuss your exact issue in detail. I assume this issue is however not specific to wsproto as a library, but applies to all server backend architectures were one connection needs to handle events and process them one by one.
Usually, an async web application (e.g. ASGI) uses one global event loop and handlers are async tasks scheduled on that event loop. If there are CPU-bound operations they are usually run in a thread using e.g. asyncio.to_thread. But
wsprotobeing a sans-IO library, nothing is async so compression ends-up blocking the event loop if data is big enough.For instance, Hypercorn uses wsproto's
Connection.send(event)here, which will compress data. I'm wondering if it's safe to run that in a thread, as it will access the connection state. Is it worth protecting that call with an async lock?Yes, protecting the wsproto resources from access across multiple threads is required.
Side comment - no real question or recommendation:
I'm curious though about performance benchmarks - creating a new thread for each event being sent might be a significant overhead and more costly than just blocking on the main thread.A new thread is not necessarily created for each sent event, it's using a thread pool.
I see compression uses zlib. It seems to be one potential CPU-bound operation. In an async framework, one would run that in a thread to avoid blocking the event loop, but since
wsprotois a sans-IO library, I don't know what to do. Running handlers in a thread in my async web framework is not an option because I need to access an object that cannot be shared between multiple threads.