Hacker News new | past | comments | ask | show | jobs | submit login

Let me try to explain. The current way (which must continue working the same way even if the language is changed) does not allow you to distinguish a goroutine that should terminate but hasn't due to some bug versus a goroutine that can legitimately run for a long time. Making the goroutine "id" explicit can allow you distinguish the two cases. Store the id in some global or long lived variable or array if you want the goroutine to run for a long time. Otherwise carefully control the scope of such an id so that the runtime has a chance to catch the first case. That is my initial thinking but it would need to be fleshed out more. For instance, there should be a way to test that goroutine has terminated. Currently you do this explicitly by passing a channel and waiting for a message.



The Go way is to pass the long running goroutines a different ctx from the short running.

Or even one ctx per goroutine and cancel them dynamically according to whatever logic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: