3 ms·

This seems really brittle. https://github.com/stealthrocket/coroutine/blob/main/getg_amd64.go https://github.com/stealthrocket/coroutine/blob/main/getg_am...

gsora 3y ago
Why?
- sctb 3y ago
  It's hardcoding an implementation detail of the Go runtime, which is subject to change (and if it did, this library might have non-obvious failure behaviour).
achille-roussel 3y ago
Yes, we planned to update the coroc compiler to generate this value instead of having it hardcoded so it will be more future proof.
deadfa11 3y ago
Eh, this one seems a reasonable trade-off to me at this point. If you try to handle every potential issue upfront, you'll never release, and this seems entirely fixable down the road. Persistent coroutines is a pretty challenging area to explore (tried this with Lua in a previous venture), and this seems a pretty minor point in that overall complexity. I'm curious, what else have you come across that justifies the "really brittle" conclusion?
- tedunangst 3y ago
  You do what you have to do, but as a user, I like to know how things will break and what my options will be. I was curious how it worked, and took a peek at the first file that seemed it might reveal something interesting.
- ilyt 3y ago
  They just seem pretty pointless as a tool in language that already have super-light green threads and good concurrency primitives.
  - pryz 3y ago
    https://research.swtch.com/coro https://research.swtch.com/coro might be an interesting read.
    - ilyt 3y ago
      Doesn't answer question "why?" In other languages they were used coz they were far lighter than native threads but that's not the case in Go
chris6f 3y ago
A source-to-source compiler, and a library that bundles runtime implementation details, was the path of least resistance. We'd love to integrate this with the Go compiler (`go build -durable`, vs. `coroc && go build -tags durable`), but the compiler is closed and maintaining a fork of Go is not feasible for us at this time.

gsora 3y ago

Why?

sctb 3y ago
It's hardcoding an implementation detail of the Go runtime, which is subject to change (and if it did, this library might have non-obvious failure behaviour).

achille-roussel 3y ago

Yes, we planned to update the coroc compiler to generate this value instead of having it hardcoded so it will be more future proof.

deadfa11 3y ago

Eh, this one seems a reasonable trade-off to me at this point. If you try to handle every potential issue upfront, you'll never release, and this seems entirely fixable down the road. Persistent coroutines is a pretty challenging area to explore (tried this with Lua in a previous venture), and this seems a pretty minor point in that overall complexity. I'm curious, what else have you come across that justifies the "really brittle" conclusion?

tedunangst 3y ago
You do what you have to do, but as a user, I like to know how things will break and what my options will be. I was curious how it worked, and took a peek at the first file that seemed it might reveal something interesting.
ilyt 3y ago
They just seem pretty pointless as a tool in language that already have super-light green threads and good concurrency primitives.
- pryz 3y ago
  https://research.swtch.com/coro https://research.swtch.com/coro might be an interesting read.
  - ilyt 3y ago
    Doesn't answer question "why?" In other languages they were used coz they were far lighter than native threads but that's not the case in Go

chris6f 3y ago

A source-to-source compiler, and a library that bundles runtime implementation details, was the path of least resistance. We'd love to integrate this with the Go compiler (`go build -durable`, vs. `coroc && go build -tags durable`), but the compiler is closed and maintaining a fork of Go is not feasible for us at this time.