Comment by exDM69 | Hacker News Reader

Comment by exDM69 | Hacker News Reader

Parent Full thread

Doesn't Go have it's own asynchronous I/O system built into the language runtime? I was under the impression that Go has I/O multiplexing w/green threads similar to Haskell. So when you write socket.read(), it will be put into an epoll/kqueue behind the scenes and a co-operative green thread switch occurs. This way you don't have to write dirty I/O callbacks like in Node.js or Boost.Asio but you get the same effect with neater code.

So if Go has this feature, using libuv would not only be useless, it would be harmful because it doesn't play nice with the language runtime w.r.t. parallelism.

I think that writing asynchronous parallel code should be done by the compiler and the runtime, not by the coder. Node.js code is a mess of callbacks that have to be written in continuation passing style by the user. Haskell (or Go?) code that has the same effect is written like regular imperative code, which is transformed into Node-style callback code by the compiler and multiplexed by the runtime. Compilers are excellent in doing this kind of transformations.

Almost, but not quite.

From http://golang.org/doc/effective_go.html#goroutines: "Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run."

So the Go runtime doesn't automagically transform blocking system calls into non-blocking calls, but if one goroutine is waiting for I/O, other goroutines can run in the meantime.

But you're right in that with Go you can write simple, easy to debug imperative code, but at the same time confidently spawn 10's of thousands of goroutines because they're so lightweight compared to conventional OS threads. The Go runtime handles the bookkeeping of multiplexing goroutines over real OS threads.

> So the Go runtime doesn't automagically transform blocking system calls into non-blocking calls, but if one goroutine is waiting for I/O, other goroutines can run in the meantime.

But when using Go's standard file.read or socket.write, what you get is I/O multiplexing of goroutines (with epoll or kqueue) in the runtime.

Naturally, if you call a C library from Go that uses unix read or write and executes a blocking system call, that cannot be magically intercepted by the Go runtime.

...what? All file.Read does is wrap the read syscall. There's no concurrency in file.Read.

It seems like goroutines in Go don't do as much asynchronous stuff as Haskell's I/O manager and green threads do. Looking at Go sources, there is some async stuff w/epoll in the net library with sockets, but file.Read is indeed just a plain syscall.

It makes me wonder, what happens to a goroutine when a system call blocks. Go is supposed to mux many goroutines to a smaller number of OS threads, but what happens when one of those threads has been blocked in a system call?

There are plenty of vague descriptions on how goroutines work but none of the ones I found quickly explained what happens on a blocking system call that allows another goroutine to run, apart from hand-waving about "another goroutine running".

The Go runtime keeps track of the number of goroutines that are currently executing and ensures that this doesn't go above GOMAXPROCS. As soon as a goroutine enters a system call it is excluded from this count. If there aren't enough threads to run GOMAXPROCS goroutines the runtime may launch a new one.

See pkg/runtime/proc.c (entersyscall, ready, and matchmg).

Half-true. os.File is not multiplexed, so if there are multiple concurrent blocking reads, each of them will consume an OS thread until it completes. net.Conn, on the other hand, uses polling so only one OS thread is necessary. Technically speaking, this is a feature of the standard library and not the runtime system.

Reply on news.ycombinator.com