Hacker News new | ask | show | jobs
by vaastav 1061 days ago
Sure but that's what the implementation of the coro in this post uses under the hood. Not sure how this is any better wrt overheads.
2 comments

Where did you get this '..it uses same under the hood'? The article clearly says:

..Next I added a direct coroutine switch to the runtime, avoiding channels entirely. That cuts the coroutine switch to three atomic compare-and-swaps (one in the coroutine data structure, one for the scheduler status of the blocking coroutine, and one for the scheduler status of the resuming coroutine), which I believe is optimal given the safety invariants that must be maintained. That implementation takes 20ns per switch, or 40ns per pulled value. This is about 10X faster than the original channel implementation.

The runtime switch was buried in the last paragraph of the article. All of the code was using goroutines and channels....
It does mention in an earlier section:

... That means the definition of coroutines should be possible to implement and understand in terms of ordinary Go code. Later, I will argue for an optimized implementation provided directly by the runtime,..

> Not sure how this is any better wrt overheads.

At the end he implements an experimental runtime mechanism that permits a goroutine to explicitly switch execution to another goroutine rather than using the generic channel scheduling plumbing.

Its in the last paragraph of the article...Very easy to miss given the code uses goroutines and channels.