Reading a bit about Go's goroutine scheduler. Sounds like it tries to solve many of the same problems a GPU's shader core does. # threads ("goroutines") >> # of simds ("OS threads"), fast switching, small stacks, minimal fairness, turn blocking calls into async calls.
-
-
The biggest practical problem is that you give up all compatibility with existing code when you go M:N (really: when you go small stacks). This means that every time you want to call an OS library you have to switch to a big stack.
-
Windows and macOS have no stable kernel API outside the system API, so that means every syscall needs a switch to a big stack. This huge cost usually outweighs all the gains of M:N. It killed M:N threading as a general solution in Rust.
- 7 more replies
New conversation -
-
-
where did you see that Windows is deprecating fibers?
New conversation -
-
-
My friend and former colleague
@BSmaalders has some hard won insight in this area. -
Sun used M:N threads initially (circa early 90s). Solaris didn't and doesn't support pagable kernel thread stacks, as a result one or two 4k pages of non-pagable memory was needed per thread. On small memory (<32M) machines this limited thread count too much. 1/
- 3 more replies
New conversation -
-
-
Solaris is the same. And Go’s M:N threading made a port of Go to sparc particularly painful. Enough that I and another developer never got the chance to finish it trying to chase down all the bugs from switching stacks. Register windows and M:N + stack switches == pain.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.