fix: Simplify provisionerd job acquire #158
Conversation
Codecov Report
@@ Coverage Diff @@
## main #158 +/- ##
==========================================
+ Coverage 67.57% 67.88% +0.30%
==========================================
Files 101 101
Lines 5101 5125 +24
Branches 68 68
==========================================
+ Hits 3447 3479 +32
+ Misses 1345 1339 -6
+ Partials 309 307 -2
Continue to review full report at Codecov.
|
75def89 to
a99ce12
Compare
| @@ -12,7 +12,7 @@ type ProvisionerJobStatus string | |||
|
|
|||
| // Completed returns whether the job is still processing. | |||
| func (p ProvisionerJobStatus) Completed() bool { | |||
| return p == ProvisionerJobStatusSucceeded || p == ProvisionerJobStatusFailed | |||
| return p == ProvisionerJobStatusSucceeded || p == ProvisionerJobStatusFailed || p == ProvisionerJobStatusCancelled | |||
5054d16 to
32a065e
Compare
This uses a simple channel to detect whether a job is running or not, and moves all cancels to be in goroutines.
32a065e to
8adf567
Compare
| acquiredJobGroup sync.WaitGroup | ||
| jobID string | ||
| jobMutex sync.Mutex | ||
| jobRunning chan struct{} |
There was a problem hiding this comment.
Would a sync.WaitGroup be a better fit here? I saw some tricky races with the initialization of the acquiredJobDone channel here: https://github.com/coder/coder/pull/148/files (specifically - the channel could be created while it was being closed or waited on).
I think a sync.WaitGroup, along with an atomic.Bool to track the running state, could accomplish the same thing
There was a problem hiding this comment.
Answered in slack - sync.WaitGroup has the same issues with the channel approach
This uses a simple channel to detect whether a
job is running or not, and moves all cancels
to be in goroutines.