Re:Go: What We Got Right, What We Got Wrong
by zozbot234 on Thursday January 04, 2024 @05:20PM
(#38873101)
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.
[ Parent
| on HN ]
Re:Go: What We Got Right, What We Got Wrong
by jtasdlfj234 on Thursday January 04, 2024 @05:40PM
(#38873293)
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.
Re:Go: What We Got Right, What We Got Wrong
by dekhn on Thursday January 04, 2024 @05:59PM
(#38873497)
In the future, I think thats what I'll say. Thanks.
Re:Go: What We Got Right, What We Got Wrong
by pcwalton on Thursday January 04, 2024 @06:02PM
(#38873526)
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.
Re:Go: What We Got Right, What We Got Wrong
by dekhn on Thursday January 04, 2024 @06:30PM
(#38873719)
but that's not really accurate. It uses system threads. Userspace threading doesn't make a transition to kernel (IIUC).
Re:Go: What We Got Right, What We Got Wrong
by pcwalton on Thursday January 04, 2024 @06:41PM
(#38873784)
Go doesn't need to transition to the kernel to switch threads, does it? It just saves and loads the register state in userland.
Re:Go: What We Got Right, What We Got Wrong
by dekhn on Thursday January 04, 2024 @06:51PM
(#38873871)
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.