It's isomorphic and better, because each goroutine performs a synchronous and easily understood acquire-perform-sleep looping operation with no hairy coordinati

It's isomorphic and better, because each goroutine performs a synchronous and easily understood acquire-perform-sleep looping operation with no hairy coordination. And even underneath, it's somewhat simpler, because neither Go nor the design I gave cares which of the runnable goroutines (the servers that have finished their work) takes the next request off the channel. Plus the blocking behaviour of channels gives you implicit backpressure if the requests are coming in too fast - the process putting them on the channel will stall.