Hacker News Reader

Comment by zozbot234 | Hacker News Reader

Goroutines use thread-per-core but run stackful fibers on top of that. (A similar model is sometimes known as "Virtual Processors" or "Light-weight processes".) This is unlike the use of stackless async-await in other languages. This peculiar use of fibers in Go is also what gets in the way of conventional C FFI and leads to quirks like cgo.

View on HN

Excellently described.

I'd love to see a resource that highlights these all on a table across programming languages as well as the associated strengths and weaknesses of such threading & concurrency models.

Perhaps a ByteByteGo graphic, if you will.

In the future, I think thats what I'll say. Thanks.

I usually just say that Go implements "userspace threading", since that's really what it is. Some early, pre-pthreads, implementations of Linux threads worked the same way as Go does and they usually called such implementations "M:N", to indicate M userspace threads mapped onto N kernel threads, so "M:N" is a good descriptor too.

but that's not really accurate. It uses system threads. Userspace threading doesn't make a transition to kernel (IIUC).

Go doesn't need to transition to the kernel to switch threads, does it? It just saves and loads the register state in userland.

IIUC it can, sometimes, avoid a kernel transition when it knows it can schedule the recipient of a message, but I believe that golang creates a threadpool for running goroutines on platforms that use thread primitives.

From https://github.com/golang/go/blob/c7d6c6000a84b61ac8bb2e38e8... I believe "worker threads" are OS threads.

Reply on news.ycombinator.com