4 ms·

Yes, that is a typo. Goroutines are multiplexed to OS threads, but this is done transparently, you don't have to worry about it. You can have tens of thousands

by luriel 15y ago

Yes, that is a typo. Goroutines are multiplexed to OS threads, but this is done transparently, you don't have to worry about it. You can have tens of thousands of Goroutines without any problems.

riffraff 15y ago
But _how_ does this actually happen? I have seen this same idea ("goroutines are very light and multiplexed into OS threads, don't worry about it") stated often, but I do not understand it, and I have not found any place where the implementation of this is actually discussed, do you have any pointers?
- ralph 15y ago
  The post you're replying to is wrong, it's not a typo; see my reply to it. For a background in the CSP languages have a browse of Russ Cox's http://swtch.com/~rsc/thread/ http://swtch.com/~rsc/thread/ The reference [4] to Squeak is broken, it's now at http://research.microsoft.com/pubs/67508/squeak.pdf http://research.microsoft.com/pubs/67508/squeak.pdf and well worth a read. For the general case, not Go specific, there's a scheduler that tracks what processes (in the CSP sense, e.g. goroutine) are waiting on what channels. Whenever a channel becomes ready, e.g. something is available to read from it, one of the processes waiting to read from it is non-deterministically (that's important) chosen and control (the CPU's program counter, still in user-space) jumps to where it returns from the `read'. It then has the CPU all to itself until it gives control back to the scheduler by needing another particular channel-state. I'm omitting sleeping, etc., for simplicity. The switching of control is all in user-space so quite lightweight.
ralph 15y ago
No, that is not a typo. A goroutine that blocks by making the thread it's currently running in block in the kernel is blocking that thread too; it must since the kernel needs some context for the on-going operation. What he's saying is that the pool of other threads used by the scheduler can continue to run other goroutines, just not the one that's blocked. No typo.

by luriel 15y ago

Yes, that is a typo. Goroutines are multiplexed to OS threads, but this is done transparently, you don't have to worry about it. You can have tens of thousands of Goroutines without any problems.

riffraff 15y ago

But _how_ does this actually happen? I have seen this same idea ("goroutines are very light and multiplexed into OS threads, don't worry about it") stated often, but I do not understand it, and I have not found any place where the implementation of this is actually discussed, do you have any pointers?

ralph 15y ago
The post you're replying to is wrong, it's not a typo; see my reply to it. For a background in the CSP languages have a browse of Russ Cox's http://swtch.com/~rsc/thread/ http://swtch.com/~rsc/thread/ The reference [4] to Squeak is broken, it's now at http://research.microsoft.com/pubs/67508/squeak.pdf http://research.microsoft.com/pubs/67508/squeak.pdf and well worth a read. For the general case, not Go specific, there's a scheduler that tracks what processes (in the CSP sense, e.g. goroutine) are waiting on what channels. Whenever a channel becomes ready, e.g. something is available to read from it, one of the processes waiting to read from it is non-deterministically (that's important) chosen and control (the CPU's program counter, still in user-space) jumps to where it returns from the `read'. It then has the CPU all to itself until it gives control back to the scheduler by needing another particular channel-state. I'm omitting sleeping, etc., for simplicity. The switching of control is all in user-space so quite lightweight.

ralph 15y ago

No, that is not a typo. A goroutine that blocks by making the thread it's currently running in block in the kernel is blocking that thread too; it must since the kernel needs some context for the on-going operation. What he's saying is that the pool of other threads used by the scheduler can continue to run other goroutines, just not the one that's blocked. No typo.