FWIW, I'm a big fan of gopkg.in/tomb.v2. For similar functionality using contexts consider golang.org/x/sync/errgroup.
On Wednesday, November 2, 2016 at 7:55:59 PM UTC-4, Gustavo Niemeyer wrote: > > 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.wa...@googlemail.com > <javascript:>> 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 <gus...@niemeyer.net > <javascript:>> wrote: > >> >> >> On Thu, Nov 3, 2016 at 1:27 AM, Axel Wagner <axel.wa...@googlemail.com >> <javascript:>> 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.
