|author||Ziheng Liu <email@example.com>||Wed Oct 23 19:31:36 2019 +0000|
|committer||Sameer Ajmani <firstname.lastname@example.org>||Thu Oct 24 00:54:14 2019 +0000|
Add critical section to protect lim.limit ***Description*** Among 9 usages of lim.limit , 8 of them are protected by `lim.mu.Lock()`, but the one at line 226 is not protected. So I add a critical section to protect the read operation. Among 8 usages of lim.limit that are protected, there are 2 usages at line 350 and 357 in function `lim.advance()`. They may seem to be unprotected at first glance, since `lim.mu.Lock()` doesn't appear in `lim.advance()`, but actually all three usages of `lim.advance()` are in critical section. ***How to trigger this bug*** I found this bug occasionally by my static checker, so I can only come up with a hypothesis to trigger it: If one goroutine is calling `rate.WaitN()` and another goroutine is calling `rate.SetLimitAt()`, then the read operation in `rate.WaitN()` and the write operation in `rate.SetLimitAt()` will race. ***About my patch*** There are several ways to fix this bug, and I chose an efficient but not elegant one. Please let me know if you think other ways are better. Change-Id: I229bc06a2caa483b9dfb0f4e682cfc144c5aa07c GitHub-Last-Rev: 192792cf2c5d0d3e8d1ac1345ead38f6ab3c46bc GitHub-Pull-Request: golang/time#7 Reviewed-on: https://go-review.googlesource.com/c/time/+/188898 Reviewed-by: Sameer Ajmani <email@example.com>
This repository provides supplementary Go time packages.
The easiest way to install is to run
go get -u golang.org/x/time. You can also manually git clone the repository to
This repository uses Gerrit for code changes. To learn how to submit changes to this repository, see https://golang.org/doc/contribute.html.
The main issue tracker for the time repository is located at https://github.com/golang/go/issues. Prefix your issue with “x/time:” in the subject line, so it is easy to find.