undefined | Better HN

0 pointsschrodinger10mo ago0 comments

Why do you encourage avoiding it? Afaik it's the only way to early-abort an operation since Goroutines operate in a cooperative, not preemptive, paradigm. To be very clear, I'm asking this completely in good faith looking to learn something new!

0 comments

sapiogram10mo ago

> Afaik it's the only way to early-abort an operation since Goroutines operate in a cooperative, not preemptive, paradigm.

I'm not sure what you mean here. Preemptive/coorporative terminology refers to interrupting (not aborting) a CPU-bound task, in which case goroutines are fully preemptive on most platforms since Go 1.14, check the release notes for more info. However, this has nothing to do with context.

If you're referring to early-aborting IO operations, then yes, that's what context is for. However, this doesn't really have anything to do with goroutines, you could do the same if the runtime was built on OS threads.

kbolino10mo ago

Goroutines are preemptive only to the runtime scheduler. You, the application developer merely using the language, cannot directly preempt a goroutine.

This makes goroutines effectively cooperative still from the perspective of the developer. The preemptive runtime "just" prevents things like user code starving out the garbage collector. To interrupt a goroutine, your options are generally limited to context cancelation and closing the channel or socket being read, if any. And the goroutine may still refuse to exit (or whatever else you want it to do), though that's largely up to how you code it.

This difference is especially stark when compared with Erlang/BEAM where you can directly address, signal, and terminate its lightweight processes.

schrodingerOP9mo ago

Exactly, thank you. I knew that the runtime gained the ability to preempt but the clear fact that you cannot get a handle to a goroutine (eg `gr := go fn()` is proof you have no way to take advantage of this ability as a user.

pjmlp10mo ago

You are expecting them to actually check the value, there is nothing preemptive.

Another approach is special messages over a side channel.

deepsun10mo ago

So instead of a context you need to pass a a channel. Same problem.

pjmlp10mo ago

Not necessarily, that is one of the reasons OOP exists.

Have a struct representing the set of associated activities, owning the channel.

ozgrakkurt10mo ago

soo, a context?

2 more replies

j / k navigate · click thread line to collapse

0 comments

sapiogram10mo ago

> Afaik it's the only way to early-abort an operation since Goroutines operate in a cooperative, not preemptive, paradigm.

kbolino10mo ago

Goroutines are preemptive only to the runtime scheduler. You, the application developer merely using the language, cannot directly preempt a goroutine.

This difference is especially stark when compared with Erlang/BEAM where you can directly address, signal, and terminate its lightweight processes.

schrodingerOP9mo ago

pjmlp10mo ago

You are expecting them to actually check the value, there is nothing preemptive.

Another approach is special messages over a side channel.

deepsun10mo ago

So instead of a context you need to pass a a channel. Same problem.

pjmlp10mo ago

Not necessarily, that is one of the reasons OOP exists.

Have a struct representing the set of associated activities, owning the channel.

ozgrakkurt10mo ago

soo, a context?

2 more replies

j / k navigate · click thread line to collapse