I might have misunderstood something but I wonder if the go-routine inside the method is really cancelled? You see, if you put a infinite loop after the ”doWorldDomination” call in the main loop, the go-routine still performs its work.
Most applications live longer and using this method would mean that goroutines arent actually cancelled.
Emmanuel, thank you, yes I think you are right. The syntax while it demonstrates the principle is buggy. It’s not actually controlling the go routine. I’ll look at this today and revise the examples. Great spot & thanks for pointing this out.
Your article is very helpful. I was also struggling to figure out how to use Context and most posts I found on the subject confused me rather than enlighten me.
I found a principle in Bill Kennedys article that I always keep in mind when it comes to context:
"Essentially, any function that is performing I/O should accept a Context value as it’s first parameter and respect any timeout or deadline configured by the caller"
Ollie, regarding the example below:
https://play.golang.org/p/Dt6fzcHF-go
I might have misunderstood something but I wonder if the go-routine inside the method is really cancelled? You see, if you put a infinite loop after the ”doWorldDomination” call in the main loop, the go-routine still performs its work.
Most applications live longer and using this method would mean that goroutines arent actually cancelled.
Just to follow up on this, I've amended the examples so that we are actually cancelling and not relying on termination. Thanks again.
Emmanuel, thank you, yes I think you are right. The syntax while it demonstrates the principle is buggy. It’s not actually controlling the go routine. I’ll look at this today and revise the examples. Great spot & thanks for pointing this out.
No, thank You Ollie!
Your article is very helpful. I was also struggling to figure out how to use Context and most posts I found on the subject confused me rather than enlighten me.
I found a principle in Bill Kennedys article that I always keep in mind when it comes to context:
"Essentially, any function that is performing I/O should accept a Context value as it’s first parameter and respect any timeout or deadline configured by the caller"
Ollie: Great article!
I think the section on 'Chaining Context' can be developed and explained more clearly along 2 main points:
1. A parent context will always impact all its descendent child contexts
2. A child context will always impact all its descendent child contexts but not its parent or ancestor contexts
In that sense, I think the Context behaves like traditional inheritance in OOP.