On Fri, 29 Jul 2022 at 11:42, Andrew MacIntyre <andy...@pcug.org.au> wrote: > > On 29/07/2022 8:08 am, Chris Angelico wrote: > > It takes a bit of time to start ten thousand threads, but after that, > > the system is completely idle again until I notify them all and they > > shut down. > > > > (Interestingly, it takes four times as long to start 20,000 threads, > > suggesting that something in thread spawning has O(n²) cost. Still, > > even that leaves the system completely idle once it's done spawning > > them.) > > Another cost of threads can be memory allocated as thread stack space, > the default size of which varies by OS (see e.g. > https://ariadne.space/2021/06/25/understanding-thread-stack-sizes-and-how-alpine-is-different/). > > threading.stack_size() can be used to check and perhaps adjust the > allocation size. >
Yeah, they do have quite a few costs, and a naive approach of "give a thread to every client", while very convenient, will end up limiting throughput. (But I'll be honest: I still have a server that's built on exactly that model, because it's much much safer than risking one client stalling out the whole server due to a small bug. But that's a MUD server.) Thing is, though, it'll most likely limit throughput to something in the order of thousands of concurrent connections (or thousands per second if it's something like HTTP where they tend to get closed again), maybe tens of thousands. So if you have something where every thread needs its own database connection, well, you're gonna have database throughput problems WAY before you actually run into thread count limitations! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
