-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reuse time.Timer in ack and rtx timer utilities #336
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #336 +/- ##
==========================================
+ Coverage 81.13% 81.18% +0.04%
==========================================
Files 49 49
Lines 3250 3247 -3
==========================================
- Hits 2637 2636 -1
+ Misses 470 469 -1
+ Partials 143 142 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@paulwe is this for performance by any chance? |
@edaniels yes, we're seeing high |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
ack_timer.go
Outdated
case ackTimerStarted: | ||
t.state = ackTimerStopped | ||
defer t.observer.onAckTimeout() | ||
case ackTimerClosed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it worth emptying t.cancel here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
state and writes to the cancel channel are synced.
- if we are in this critical section and the state is
started
we cannot have written tocancel
. - if we change the state from
started
tostopped
in this critical section then callstop
afterward the state will bestopped
and we won't won't write tocancel
. cancel
could be dirty if the state isclosed
but we won't reuse the timer later so we don't care.
ack_timer.go
Outdated
} | ||
|
||
cancelCh := make(chan struct{}) | ||
t.state = ackTimerStarted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a chance of race here? Is there a need to drain timer channel or t.cancel?
Thinking aloud
stop()
called: that will write tot.cancel
and set state tostopped
- Assume, the go routine below has not drained
t.cancel
yet. start()
happens: this will try to restart the timer as state isstopped
- This will launch another go routine. Will this clash with go routine in Step 2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch. invocations of the callback are interchangeable and for this to happen the time between calls has to be practically zero so we can eat the extra cancel and the earlier goroutine will serve as the timeout for the latest call to start.
415e0bb
to
9fb4b50
Compare
No description provided.