Glad it's being useful, and indeed, that API looks familiar. Nice. On Nov 3, 2016 4:33 PM, "Chris Hines" <ggro...@cs-guy.com> wrote:
> 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> 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> >> wrote: >> >>> >>> >>> On Thu, Nov 3, 2016 at 1:27 AM, Axel Wagner <axel.wa...@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. > -- 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.
