coroutines for go

[Ugorji]

I read Russ' 2023 article on coroutines for go (https://research.swtch.com/coro) with joy. I've found the natural ways of writing parsers (and comparing trees) would be very elegant using goroutines and channels, but the performance cost makes it non-ideal, especially when creating a reusable library.

Since the article was posted, I've not seen or heard anything from the core team about it.

Is this something that is being worked on, could see the light of day soon (e.g. 2023)?

[Jorropo]

Coroutines are implemented in the go compiler's runtime and exposed as an internal package and are used to transform push iterators into pull ones in the iter package.

https://github.com/golang/go/blob/2e1003e2f7e42efc5771812b9ee6ed264803796c/src/iter/iter.go#L31-L32

You can play with them using `go:linkname` but the API is unlikely to be great and this definitely won't fall under the compatibility promise.

You can safely (rangefunc) emulate coroutines using push iterators and using `range` keyword and `iter` std package altho it's not as efficient as control flow inversion (compiler made, codegen-ed or man made) and the API wont fit great since it's made for the less general subset: generators.

[David Chase]

Do not rely on the existence of coroutines yet; it turns out that they have an unpleasant interaction with LockOSThread, and every stone we turned over had more bugs under it.  What will actually get implemented for Pull is a little bit up in the air because of this.  (I am on team "goroutines are correct, start from that, everything else is an optimization").

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAHWihb9PH0J21CUYQMcJoMtus%2B%3DLJ_HpTkFwpvisOHEYFyap7Q%40mail.gmail.com.

[Ugorji Nwoke]

Thank you all so much. I didn't realize all this was already being worked on in earnest.

You received this message because you are subscribed to a topic in the Google Groups "golang-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-dev/hgRVxGeZFZg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAHOpXeW5SAXqHichH0A%3DvHdoTX1ZbVHHtFrtG6-AShMUCsag-g%40mail.gmail.com.

[Andrew Phillips]

According to 1.23 draft release notes use of go::linkname is being tightened.
See https://tip.golang.org/doc/go1.23#:~:text=linker%20now%20disallows

[tapi...@gmail.com]

> I've found the natural ways of writing parsers (and comparing trees) would be very elegant using goroutines and channels, but the performance cost makes it non-ideal, especially when creating a reusable library.

It is just because how the current goroutines+channels are implemented. They can be implemented as performant as coroutines (without threads/processers).

[Ethan Reesor]

Are these discussions publicly visible (e.g. on GitHub/Gerrit/etc)? I'm purely curious, I would find it interesting to read through the problems that have been discovered.

[Ian Lance Taylor]

On Wed, Jun 26, 2024 at 12:43 PM Ethan Reesor <firel...@gmail.com> wrote:
>
> Are these discussions publicly visible (e.g. on GitHub/Gerrit/etc)? I'm purely curious, I would find it interesting to read through the problems that have been discovered.

https://go.dev/issue/67499

Ian

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/5ad855e3-0a2a-4751-9a5f-4cf1d3858c48n%40googlegroups.com.