[fulafel]

This take on native threads sounds overly pessimistic. 99% of backends do fine with the nr of native threads you can easily run in a single process at least on Linux. Not sure what the practical limit is now but 10k used to be no problem many years ago.

(eg 100k threads in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. where the 32-bit 4 GB limit seemed to be the main obstacle)

[traderj0e]

I believe it's fine when you're tuning it. Nowadays people are more likely to have multiple services waiting on each other to handle a user request, each running in containers on random hardware. Even if it's "monolithic," it's probably not really cause they're waiting on external APIs. They don't want to think about tuning for thread pools too.

[fulafel]

I can believe some people have implemented misconfigured thread pools, being worse off than with no thread pool at all. But this not an argument that justifies a "multitasking isn't a real choice for backends" position.

(Then there's bugs that happen in both asyncio and threaded programs, that stem from various queuing problems in the system, manifesting as work getting backed up in the concurrency layer. You end up needing backpressure in both worlds, thread pool limits are the wrong layer to do it.)