Can any one explain why go doesn't handle file I/O as the same as net I/O by using netpoller?

Go is better at net I/O than file I/O.Why not handle the file I/O as same as net I/O? What’s the difference between them?

Hi @cwww3, welcome to the forum.

What do you mean by, “is better at”? Better in which aspect(s)?

It is my understanding that file I/O will consumer M and block it .Then P will hand off M to found new M.
But net I/O will not block M.

(for other readers, @cwww3 refers to the concept of Go’s work-stealing scheduler as explained in the linked blog article by rakyll.)

I am not familiar with the internals of file I/O vs net I/O in Go, so I have to mostly refer to other sources here. I hope these can contribute to this topic.

This commit (found here) indicates that Go uses the runtime poller for file I/O where possible. Operating systems seem the limiting factor here; for example, epoll on Linux does not support normal files. See also this comment in Go issue #6817.



Late update but maybe still of interest (or of interest to other readers): This article from Bill Kennedy (Ardan Labs) includes a detailed look into asynchronous versus synchronous I/O from a goroutine scheduling perspective:

(Scroll down to the paragraph “Asynchronous System Calls”)

The article is part of a 3-article series about concurrency and the Go scheduler. A very long but interesting read.

1 Like