On Saturday, 28 March 2015 at 11:52:34 UTC, Sönke Ludwig wrote:
You can access TLS from an event callback just as easy as from a fiber.
Yes, but it is much easier to verify that you don't hold onto references to TLS if get rid of arbitrary call stacks when moving to a new thread.
And why can't you do the same with fibers and schedule the fibers accordingly?
You could, but that's even more work since you then need to encode progress in a way the scheduler can use to estimate when the task can complete and when it must complete.
It's you who brought up the randomization argument. Tasks are assigned to a more or less random thread that is currently in the scheduling phase, so that your constructed situation is simply *highly* unlikely.
I don't understand how randomization can help you here.
They *do* get balanced over threads, just like requests get balanced over instances by the load balancer, even if requests
A good load balancer measure back-pressure (load information from the instance) and fire up new instances.
are not moved between instances. But IMO it doesn't make sense to go further with this argument with some actual benchmarks. It's not at all as clear as you'd like what the effects on overall performance and on average/~maximum latency are in practice for different applications.
This is something you can do on paper. A language feature should support a wide set of applications.
