Go with blocking I/O

[methane]

While this is not regular Go program, it's interesting.

[jonhoo]

I wasn't aware that file operations behaved differently from network operations in this way..? Do you have a link to the documentation or something where this is explained?

Also, I'd like this to be in a separate directory inside servers/; each directory should contain only one implementation. If you could make the PR use a directory gobio (for "Go blocking I/O") instead, that would be great.

[methane]

You can easily confirm with strace. On Linux, file I/O doesn't support non-blocking I/O. Many event-driven framework use threadpool for file operation. In golang, monitor thread detects blocked system call and assign new thread to waiting goroutines.

Here is source code of net's Read(): https://github.com/golang/go/blob/master/src/net/fd_unix.go#L228-L234 As you can see, try (non-blocking) read, and if EAGAIN, pd.WaitRead(). It's epoll on Linux.

Here is file's Read(): https://github.com/golang/go/blob/master/src/os/file_unix.go#L211 It just calls (blocking) read syscall once.

[jonhoo]

Benchmarking this would certainly be interesting. If you move it into its own directory, I'll merge and benchmark.

[methane]

And here is how TCPConn.File() works: https://github.com/golang/go/blob/master/src/net/net.go#L239-L240 https://github.com/golang/go/blob/master/src/net/fd_unix.go#L534-L549

It dup() fd and set blocking mode.

[jonhoo]

Almost there. go/Makefile still contains rm blocking.

[methane]

fixed.

[diegobernardes]

+1 want to see this benchmark

[jonhoo]

Thank you @methane! I'll post benchmark results as soon as I have them.

[jonhoo]

Benchmark results are now up. Performance is much better, though I'm also seeing quite a lot of variance in the results for go-blocking -- not entirely sure why that is.