> You're basically asking ... No. > So yes the article's argument about time wasted on schedule makes a whole lot of sense because ... context switches ... R

> You're basically asking ... No. > So yes the article's argument about time wasted on schedule makes a whole lot of sense because ... context switches ... Right. I understand that doing multi-tasking closer to the application code can be more efficient by avoiding involving the kernel and context switching. What I was wondering about was this specific argument that the article was making: Suppose for a minute that in your new system, switching between new threads takes only 100 nanoseconds. Even if all you did was context switch, you could only run about a million threads if you wanted to schedule each thread ten times per second. More importantly, you’d be maxing out your CPU to do so. Supporting truly massive concurrency requires another optimization: Only schedule a thread when you know it can do useful work! If you’re running that many threads, only a handful can be be doing useful work anyway. Go facilitates this by integrating channels and the scheduler. If a goroutine is waiting on a empty channel, the scheduler can see that and it won’t run the Goroutine. Doesn't the OS also perform this optimization, i.e., only scheduling threads that can do useful work? If you have thousands of threads that are all sleeping or blocking on read, it was my understanding that the OS will not schedule them – contrary to what the article is saying above. Am I wrong about this?