go-multiplex: Port rust-multiplex to go

[jonhoo]

Thanks! I'll benchmark this on Monday. As you pointed out on golang-nuts, both of these servers are sort of cheating -- it is not realistic that every client will always have something to do, and so these servers would end up blocking unnecessarily in a real-world use-case. The reason I implemented it in Rust is that it is a half-way stop towards full async I/O (using mio); when I get a proper mio implementation, that will replace rust-multiplex entirely. For Go it makes less sense since the idiomatic solution is already using async I/O.

[xekoukou]

go-multiplex vs rust-multiplex is a fair game. But wouldn't that mean that goroutines have lost,whichever the outcome, as you need to reuse a goroutine to have similar performance.

[jonhoo]

This doesn't run correctly on my machine. The client hangs forever (seemingly) after "priming with 25000 iterations across 40 clients". Have you tried running the benchmark yourself with a smaller number of cores to check that it works?

[methane]

This doesn't run correctly on my machine. The client hangs forever (seemingly) after "priming with 25000 iterations across 40 clients". Have you tried running the benchmark yourself with a smaller number of cores to check that it works?

Yes. It runs when GOMAXPROCS=8 and client -c8. But I confirm it doesn't run with GOMAXPROCS=40 and client -c40. I'll dig it in tomorrow.

[methane]

I see. Rust's mpsc::channel is infinite queue but Go's channel is finite queue. I've fixed problem.

[jonhoo]

The Makefile clean target still says go, not go-multiplex.

[jonhoo]

As previously mentioned, I'm hesitant to merge this since rust-multiplex is really just a placeholder for rust-mio. You would probably not write your server application this way because, as someone (you?) pointed out, it's not clear that it's that all clients always have outstanding requests.