Kernel threads for IO do not work great (I'd be happy to provide more info), which is why async IO is needed. Not using an M:N model to keep compatibility with C is certainly reasonable, but goroutines and an M:N model do have many advantages over kernel threads for doing IO.https://twitter.com/pcwalton/status/1140983747379990528 …
-
-
Replying to @kkourt
Why did Linux and Solaris kill M:N in favor of 1:1 then?
2 replies 0 retweets 1 like -
Complexity. The dynamic coupling between user and kernel contexts, and controlling the kernel thread pool caused edge-case driven nightmares. Great set of comments that walk through the complexities in Solaris, but I can't find it now.
1 reply 0 retweets 0 likes -
Replying to @__gparmer @kkourt
That would seem to argue against M:N systems like Go, right?
1 reply 0 retweets 0 likes -
Go is not m:n in the way that Scheduler Activations and Solaris envisaged them. Go is M:1 with a library-managed thread pool for making blocking I/O requests, similar to how event libraries (eg libuv) manage blocking.
3 replies 0 retweets 1 like
Go isn't M:1, it's work stealing over N kernel level threads.
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.