-
Notifications
You must be signed in to change notification settings - Fork 343
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
Protect stats with RWMutex #151
Conversation
Yessssssssssssssssssss. |
Revisiting this, I think it could be possible to add a unexported uint64 (or int64) for packetsSent and duplicatesrecv. The exported fields can stay there and be updated as they are right now, but they wouldn't be used in Statistics(). |
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.
Nice one! It's a 👍 from me for a squash-and-merge.
Edit: looks like there's an issue with CircleCI so I can't see why the build is broken but I suspect it's #148.
updateStats() now also updates rtts so it is protected by the lock. Statistics() should now be callable from other goroutines. PacketsSent and PacketsRecvDuplicates can still be updated while Statistics() is running, and thus could yield strange results (sent<recv) To fix this, atomics could be used, but it would require changing the types of the fields from int to int64, thus changing the public api. Signed-off-by: Jean Raby <jean@raby.sh>
Rebased |
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
This is more of a request for comments than a proper PR (and it is branched off #150 so only the last commit should be reviewed )
A RWMutex is added to protect access to the Pinger's internal statistics.
Updates to
rtts
is moved toupdateStats
so they happen under the lock.There's (at least) one issue however: PacketsSent and PacketsRecvDuplicates can still be updated while
Statistics() is running, and thus could yield strange results (sent<recv)
To fix this, atomics could be used, but it would require changing the types of the fields from int to int64, thus changing the public api of Pinger. (One could argue that those fields should probably not be exported to begin with, but that would break the api too)
Any thoughts?