One possibility:
func (s *SimplePeerConn) Read(b []byte) (n int, err error) {
ctx, maybeCancelFn := func() (context.Context, context.CancelFunc) {
s.deadlineLock.RLock()
defer s.deadlineLock.RUnlock()
if !s.readDeadline.IsZero() {
return context.WithDeadline(context.Background(), s.readDeadline)
}
return context.Background(), nil
}()
if maybeCancelFn != nil {
defer maybeCancelFn()
}
return s.ReadWithContext(ctx, b)
}
But still a bit annoying to have go vet try to capture these use cases.
Maybe the cancel fn leak test should have a better reachability algo or a
reduced set of parameters where it's considered unreachable (i.e. when the
var is used in other ways)?
On Monday, February 6, 2017 at 3:35:05 PM UTC-6, Chad Retz wrote:
>
> I have the following function:
>
> func (s *SimplePeerConn) Read(b []byte) (n int, err error) {
> ctx := context.Background()
> var maybeCancelFn context.CancelFunc
> func() {
> s.deadlineLock.RLock()
> defer s.deadlineLock.RUnlock()
> if !s.readDeadline.IsZero() {
> ctx, maybeCancelFn = context.WithDeadline(ctx, s.readDeadline)
> }
> }()
> if maybeCancelFn != nil {
> defer maybeCancelFn()
> }
> return s.ReadWithContext(ctx, b)
> }
>
> And I'm getting a possible context leak when I assign maybeCancelFn. I
> originally had context.WithCancel and then overwrote the cancelFn in the
> inner func.
> How would I idiomatically rewrite this to not see the vet error?
>
--
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.
