Context / Cancellations

[mingue]

The context package in my view is probably the worst addition. It should be integrated into the language to make cancellation and scoped information trivial to use.

• Use of context requires to pass it everywhere breaking existing APIs or making WithContext equivalent to every method. This is a terrible practice impacting work on cross cutting concerns.
• context.WithValue is not typed as it was designwd before the introduction of generics, and even with that generics don't support types on methods. There should be a better way of passing values on a scoped context without requiring to pass context and cast values out of it.

A possible solution will be to have a default context per goroutine and goroutines should inherit from the one that triggered them to allow for easy propagation.

On blocking operations where go is yielding to other goroutines it should check if context is cancelled to avoid progressing any further.

Java and project loom seem to have learned from Go and avoid these mistakes.

[avivcarmis]

Interesting. Any specific reading material on how they handled timeouts and cancellations in prj loom?

Something like this can be very challenging to implement, since we have to direct impact on runtime. But we probably can figure it out in the produced go code.

My first question - what happens if a goroutine has to execute with several specific timeouts? For example, i have a single goroutine to execute serially 2 distinct http calls, each with a different timeoit?