cancel is a library which is made to just be a simple form of context.Context.
What we wanted was a library to cancel tasks safely. context.Context does this, but it
provides several other features and complications we didn't ask for, such as
a (really) complex WithValue and tons of forward and back references.
It's not super optimized at the moment, but I wanted to make sure it was easy to use.
A Canceller is cancelled in one of three ways:
- If its cancel function is called
- If its deadline is reached
- If its parent is cancelled
Well, I haven't written benchmarks yet. I'm not exactly a benchmark writer, so if someone else wants to do that, that'd be awesome.
Cancel is much more readable and understandable as to how it works. If you look at the
implementation of context, it gets really complex really fast. I'm hoping it's
more memory and time efficient than context, although I'm not entirely sure.
Since the standard library uses context everywhere (for obvious reasons), there
is a function to convert a Canceller to a Context, cancel.Context(canc)
cancel is a go module which is go-gettable. This means you will be able to fetch any version
of cancel that you want, and it will be compatible with the semantic versioning guarantee.
It is notable however that (as of me writing this README) the current major version is v0, so there are no compatability guarantees until v1, which should be coming soon.
You will find many similarities to context.
Root Canceller:
cancel.NeverCancel()
With a deadline:
canc := cancel.NeverCancel()
canc, f = cancel.WithDeadline(canc, time.Now().Add(5 * time.Second))
defer f()
// or more simply
canc, f = cancel.WithTimeLimit(canc, 5 * time.Second)
defer f()
With a cancel function:
canc, f = cancel.WithCanceller(canc)
// call f when you want to cancel
I want to allow WithDeadline and WithTimeLimit to not return cancel functions. Currently
they do because creating them spins up a goroutine. Therefore the only two ways to
end the goroutine is to either reach the deadline or to cancel the parent. Perhaps this
is negligible, although I want to allow for efficient programming with this.
Perhaps instead of having cancel.WithDeadline(canc, t), it should be canc.WithDeadline(t).
It makes more intuitive sense for them to be methods rather than package-level functions.