You said the function would return whether it got cancelled or not, so I assumed something like err := foo.CallAPI(ctx), which would be awkward to return without actually canceling.
Yes, if the function is documented to return with background activity, it's of course fine. That said, It's extremely helpful to be able to reliably cancel such background activity and wait until it's done, for a number of reasons: side effect control, testing, polite shutdowns, etc. That's mainly where gopkg.in/tomb.v2 comes from. On Nov 3, 2016 1:43 AM, "Axel Wagner" <axel.wagner...@googlemail.com> wrote: In a concurrent world, assuming that a call to cancel means that thing actually got cancelled is dubious at best. For example, you could call cancelFunc, then immediately enter a GC pause, the other goroutine finishes their work in a orderly fashion, you unpause and close the underlying channel. Very normal behavior, perfectly valid code, unpreventable situation. But still, calling cancelFunc doesn't mean it actually had any real effect. This is what I mean by "successful cancellation" (or not). I don't believe we actually disagree. Though there might be some phrasing issue. Which is now adding more noise and confusion (sorry. I'll shut up now). On Thu, Nov 3, 2016 at 12:31 AM, Gustavo Niemeyer <gust...@niemeyer.net> wrote: > > > On Thu, Nov 3, 2016 at 1:27 AM, Axel Wagner <axel.wagner...@googlemail.com > > wrote: > >> That is actually a great point I haven't thought about and the crux of >> the matter (sorry for repeating it, but I think it's worth making very >> explicit): >> >> While cancelFunc can only be called from the goroutine that created the >> context, Err can be called downstack. Meaning, if I call cancelFunc, a call >> *might or might not* return Cancelled as an error. It might not actually >> implement cancellation or the call might have failed or succeeded >> concurrently with a different (non-)error. >> >> The ctx.Err() return thus allows a "child-function" to signal back >> whether a cancellation was *successful*; the creator of the context only >> know that it has been *tried*. >> > > No, that's really not its intent. Cancel means *STOP IT!*, and any > goroutines down the chain are supposed to block until they're really done, > returning ASAP. > > It's a nasty bug to disrespect that, because the call site will assume > that the background noise stopped once the function returned, and act > accordingly thereafter. > > > gustavo @ http://niemeyer.net > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
