On Fri, May 31, 2024 at 12:09 PM Haoyang Fan <haoyangfa...@gmail.com> wrote: > > I was always under the impression that Go solely uses async I/O under the > hood so that when invoking a seemingly blocking call like os.File.Read the > underlying thread won't be blocked. Go scheduler will save the context of > current goroutine and schedule other goroutines to run on that thread. This > understanding seems to be aligned with most material I can find on the > internet.
That is how it works for most operations. That said, since you specifically mentioned os.File.Read, if the os.File is a disk file, then on most Unix systems the goroutine and the underlying thread will indeed block for the duration of the I/O. That is because most Unix systems have no mechanism for non-blocking I/O for disk files, so the I/O does block the underlying thread. The underlying thread will not block for I/O on a network connection or a pipe. As a practical matter this is only relevant when using a networked file system, as local file systems are fast. > However, recently when I was reading the slides > (https://go.dev/talks/2012/waza.slide#32), on slide 32 I notice it says "When > a goroutine blocks, that thread blocks but no other goroutine blocks". This > is contradictory and make me wonder does Go really perform I/O in an > asynchronous manner (e.g. like select/poll/epoll in Linux) under the hood? > > Can somebody please clarify? That talk is from 2012. The network poller and scheduler have been rewritten since then. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVXYzWZZ881Si%2B6YcxVbsdme%3DcomqoiutGyx4o0g5SCBQ%40mail.gmail.com.
