Coroutines and Fibers: Why and When

  local player = nil
  while(player == nil) do
    yeild(0)
    player = LookForPlayer(...)
  end
  
  while(WalkTowardsPlayer(player)) do
    yeild(0)
  end

  while(!PlayerDead(player)) do
    MeleePlayer(player)
    yield(0)
  end

'Fair scheduling' - nobody writes single threaded programs that process requests sequentially. It's either a thread-per-request system vs. a coroutine-per-request system. Threads are generally going to be more fair at scheduling since they are preemptive. Most coroutines are cooperative (Python, Lua) - so a long running coroutine (stuck doing some CPU cycle) will block all other inflight requests and cause latency variance. Some systems are preemptive (Erlang) so they don't suffer from the variance.

The benefit of coroutines is you can have a very large number of coroutines, probably orders of magnitude more than the number of threads - so coroutine-per-request models will scale much more than threads-per-request. The article is spot on about the context switching cost - it's so much cheaper to switch between coroutines.

You can also use multiple request per threads and use async IO, but that's the same as using coroutines with a much worse programming model.

for anyone interested in using fibers inside a java webapp, i just wrote up a quick survey of async java servlet performance: http://blog.nqzero.com/2016/01/asynchronous-java-webserver-h...

(based TechEmpower plaintext benchmark, but limited to java async)

the model is that you use async in the server, and then bridge to a fiber implementation and then complete the async response when the fiber completes. for handling high latency low cpu processing on the server, this technique allows handling a huge number of connections