Skip to content

Commit ebebde1

Browse files
authored
Batch closer can wait merely on the closer goroutines (treeverse#1392)
Simplifies using a waitgroup, which is now a regular blocker usage (Add only called at startup) rather than dynamically increasing and decreasing. This way does not have to synchronize as closely across the waitgroup.
1 parent f864e32 commit ebebde1

File tree

1 file changed

+2
-3
lines changed

1 file changed

+2
-3
lines changed

graveler/committed/batch.go

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,6 @@ type BatchCloser struct {
1616
err error
1717

1818
wg sync.WaitGroup
19-
2019
ch chan ResultCloser
2120
}
2221

@@ -27,6 +26,7 @@ func NewBatchCloser(numClosers int) *BatchCloser {
2726
ch: make(chan ResultCloser),
2827
}
2928

29+
ret.wg.Add(numClosers)
3030
for i := 0; i < numClosers; i++ {
3131
go ret.handleClose()
3232
}
@@ -51,7 +51,6 @@ func (bc *BatchCloser) CloseWriterAsync(w ResultCloser) error {
5151
return bc.err
5252
}
5353

54-
bc.wg.Add(1)
5554
bc.mu.Unlock()
5655
bc.ch <- w
5756

@@ -62,10 +61,10 @@ func (bc *BatchCloser) handleClose() {
6261
for w := range bc.ch {
6362
bc.closeWriter(w)
6463
}
64+
bc.wg.Done()
6565
}
6666

6767
func (bc *BatchCloser) closeWriter(w ResultCloser) {
68-
defer bc.wg.Done()
6968
res, err := w.Close()
7069

7170
// long operation is over, we can lock to have synchronized access to err and results

0 commit comments

Comments
 (0)