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?
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.
Thanks.
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.