The MT context currently starts a fixed number of threads immediately. If we set a size of 32, then all 32 threads will be started, then the program will continue. This leads to a couple issues:
all these threads will immediately start spinning (nothing to do) and park themselves before the context receives a fiber to run;
starting all these threads creates a delay (we wait for them to be started);
we may not need all these threads now (slow traffic), or we may only need them much later (increasing traffic), or don't need them anymore (slow traffic again).
For starters, we could dynamically start threads up to size when fibers are enqueued (after checking for spinning and parked threads). That would avoid issue 1, 2 and half of issue 3.
In a second time, instead of a fixed size the context could take a range with a minimum (optional) and a maximum (required) number of threads to keep running; for example 1..12 or ..4, and dynamically start & stop new threads on demand. To avoid too many stops & restarts, threads would park themselves with a timeout, and only stop when that timeout is reached. That would avoid the second half of issue 3.
The above has been implemented with the exception of threads eventually stopping themselves. We'll see that later, if needed.
The MT context currently starts a fixed number of threads immediately. If we set a size of 32, then all 32 threads will be started, then the program will continue. This leads to a couple issues:
For starters, we could dynamically start threads up tosizewhen fibers are enqueued (after checking for spinning and parked threads). That would avoid issue 1, 2 and half of issue 3.In a second time, instead of a fixed size the context could take a range with a minimum (optional) and a maximum (required) number of threads to keep running; for example1..12or..4, and dynamically start & stop new threads on demand. To avoid too many stops & restarts, threads would park themselves with a timeout, and only stop when that timeout is reached. That would avoid the second half of issue 3.The above has been implemented with the exception of threads eventually stopping themselves. We'll see that later, if needed.