On 01/04/2017 10:39 PM, Garrett D'Amore wrote:
It actually typically uses 2 threads per socket, and 2 threads per underlying
connection.
This could be altered to use a co-routine library, and its designed to
support that as part of platform porting.
Having said that, I’m *strongly* of the opinion that given a robust and
non-crappy threads implementation, that
threads will perform and scale quite highly. Most of the complaints about
thread scalability come from three areas:
a) Poor application/library design leading to lots of lock contention.
Uncontended mutexes are cheap. Contended ones
are not. I’ve designed to minimize contention.
b) Stack consumption. Generally threads *do* each have their own stack.
I’ve taken care to keep my stacks shallow,
so its unlikely that we would ever need more than a single page per thread.
At 4K page sizes, this means that you can
have 1000 threads (around 500 connections) in only 4MB RAM. If you need 1M
connections, you might feel the problem.
You’ll run out of TCP ports first though.
c) Crappy threading implementations. This is largely a thing of the past.
Modern thread libraries are quite
performant and scale particularly well.
Conversely, threading leads to inherently better multi-core scalability,
giving huge performance wins on larger
systems. And, as a particularly nice bonus, the logic flow in single threads
is *lots* easier to understand.
Anyway, so that’s my thinking. Once I’ve gotten a little further we will be
able to test these theories with actual
scalability and performance tests. If it turns out that I’ve misjudged, it
will still be possible to retrofit some
kind of coroutine API.
