Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Durable Coroutines for Go

github.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Durable Coroutines for Go

#31

Post by hnav »

chris6f wrote: post #23
hnav wrote: post #21

I feel like once serializing god-knows-what state across program invocations is a requirement, I'd much prefer writing this explicitly so I can at least have a chance of debugging it type Task struct { I int } func (t *Task) Next() (bool, int) { if t.I

It's a good point, but the entire program would have to be written this way (you can't use the standard library, or any other dependencies). What if there were tools to inspect and debug the coroutine state? That's an area we're exploring now.

But doesn't the program have to be written explicitly anyway? Like what happens if I open a file or network connection, yield, and then resume on another system?

Re: Durable Coroutines for Go

#33

Post by chris6f »

hnav wrote: post #31
chris6f wrote: post #23

Earlier quoted context omitted.

It's a good point, but the entire program would have to be written this way (you can't use the standard library, or any other dependencies). What if there were tools to inspect and debug the coroutine state? That's an area we're exploring now.

But doesn't the program have to be written explicitly anyway? Like what happens if I open a file or network connection, yield, and then resume on another system?

It's probably better to let the user/application decide what to do in these cases, and for this reason we allow them to register type-specific (de)serialization routines.

In the case of network connections, the user could instead serialize connection details and then recreate the connection when deserializing the coroutine state. Same thing for files, where instead of serializing unstable low-level details like the file descriptor, the user can instead serialize higher level information (path, open flags, etc) and recreate the open file when deserializing the coroutine state.

Re: Durable Coroutines for Go

#34

Post by pryz »

varispeed wrote: post #30

Why not fork Go and implement this directly? (and also removing any telemetry Google might have installed while at it...)

Forking Go means that you have to maintain a copy. That's a lot of work. Instead, the idea is to implement coroutine as a library and work toward an integration with the Go stblib.

Re: Durable Coroutines for Go

#37

Post by ilyt »

pryz wrote: post #29
ilyt wrote: post #27

Earlier quoted context omitted.

They just seem pretty pointless as a tool in language that already have super-light green threads and good concurrency primitives.

https://research.swtch.com/coro might be an interesting read.

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

Post reply on HN