[gi0baro-dev]

Granian maintainer here.

While it might sound "odd", actually having two runtimes running in two different threads is not so strange. This is actually what you end up when spawning multiple Python processes even with uvicorn: each process will have the asyncio event-loop running in the main thread.

In Granian the Python runtime and the Rust ones communicate with each other in a non-blocking way, so – theoretically speaking – there's no additional CPU-bound load compared to a pure Python solution.

Also, theoretically speaking, the only condition I can imagine where the two runtimes fight too much with each other is in case where you have a single core system with so poor performance to not handle 2 threads concurrently, which is probably so rare that we don't need to think about it..

Probably I should add some resource usage tests aside to benchmarks, but – again, theoretically speaking – if the Rust code is more efficient than the Python one, the final CPU usage should be lower, or more efficient.

[WhyNotHugo]

Thanks for your reply! Indeed, this should still be more efficient than a pure-python approach.

My main confusion around this is: how do I scale threads? Say I have to CPU cores. Do you run one Granian thread and one python thread? I Granian under-uses CPU, Python can't use the excess. But if I run one Granian thread and two python threads, I risk Python leaving Granian with less CPU than it needs.

In practice it should not be hard to find a balance... but somehow I'm still bothered by the fact that the design has no obvious solution for this.