News for hackers. Stuff that matters.
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.
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.