undefined | Better HN

0 pointsfulafel12d ago0 comments

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)

0 comments

traderj0e12d ago

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.

fulafelOP10d ago

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.)

j / k navigate · click thread line to collapse

0 comments

traderj0e12d ago

fulafelOP10d ago

j / k navigate · click thread line to collapse