Race in queue code #22145
Labels
Comments
|
@zeripath fyi |
|
I think that's more likely a race in the test. Not the code itself. |
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
Dec 15, 2022
There are a few places in FlushQueueWithContext which make an
incorrect assumption about how `select` on multiple channels works.
The problem is best expressed by looking at the following example:
```go
package main
import "fmt"
func main() {
closedChan := make(chan struct{})
close(closedChan)
toClose := make(chan struct{})
count := 0
for {
select {
case <-closedChan:
count++
fmt.Println(count)
if count == 2 {
close(toClose)
}
case <-toClose:
return
}
}
}
```
This PR double-checks that the contexts are closed outside of checking
if there is data in the dataChan. It also rationalises the WorkerPool
FlushWithContext because the previous implementation failed to handle
pausing correctly. This will probably fix the underlying problem in
go-gitea#22145
Fix go-gitea#22145
Signed-off-by: Andrew Thornton <art27@cantab.net>
|
It would also fix the test error here: https://drone.gitea.io/go-gitea/gitea/64883/2/13 |
lafriks
pushed a commit
that referenced
this issue
Dec 30, 2022
There are a few places in FlushQueueWithContext which make an incorrect
assumption about how `select` on multiple channels works.
The problem is best expressed by looking at the following example:
```go
package main
import "fmt"
func main() {
closedChan := make(chan struct{})
close(closedChan)
toClose := make(chan struct{})
count := 0
for {
select {
case <-closedChan:
count++
fmt.Println(count)
if count == 2 {
close(toClose)
}
case <-toClose:
return
}
}
}
```
This PR double-checks that the contexts are closed outside of checking
if there is data in the dataChan. It also rationalises the WorkerPool
FlushWithContext because the previous implementation failed to handle
pausing correctly. This will probably fix the underlying problem in
#22145
Fix #22145
Signed-off-by: Andrew Thornton <art27@cantab.net>
Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
Jan 13, 2023
Backport go-gitea#22146 There are a few places in FlushQueueWithContext which make an incorrect assumption about how `select` on multiple channels works. The problem is best expressed by looking at the following example: ```go package main import "fmt" func main() { closedChan := make(chan struct{}) close(closedChan) toClose := make(chan struct{}) count := 0 for { select { case <-closedChan: count++ fmt.Println(count) if count == 2 { close(toClose) } case <-toClose: return } } } ``` This PR double-checks that the contexts are closed outside of checking if there is data in the dataChan. It also rationalises the WorkerPool FlushWithContext because the previous implementation failed to handle pausing correctly. This will probably fix the underlying problem in go-gitea#22145 Fix go-gitea#22145 Signed-off-by: Andrew Thornton <art27@cantab.net> Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath
added a commit
that referenced
this issue
Jan 13, 2023
Backport #22146 There are a few places in FlushQueueWithContext which make an incorrect assumption about how `select` on multiple channels works. The problem is best expressed by looking at the following example: ```go package main import "fmt" func main() { closedChan := make(chan struct{}) close(closedChan) toClose := make(chan struct{}) count := 0 for { select { case <-closedChan: count++ fmt.Println(count) if count == 2 { close(toClose) } case <-toClose: return } } } ``` This PR double-checks that the contexts are closed outside of checking if there is data in the dataChan. It also rationalises the WorkerPool FlushWithContext because the previous implementation failed to handle pausing correctly. This will probably fix the underlying problem in #22145 Fix #22145 Signed-off-by: Andrew Thornton <art27@cantab.net>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Looks like there is still a race in the queue code:
Gitea Version
main
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://drone.gitea.io/go-gitea/gitea/64466/2/14
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
CI
Database
None
The text was updated successfully, but these errors were encountered: