Conversation
This was rather hard to track down, but what I noticed was hanging/leaking goroutines waiting on `<-p.buf`. This came up during hunting race conditions. What happened here was that the gorouting that executed `opFunc` could never return because the operator was somewhere trying to `Pull`. Which in turn meant waiting on a message recievied `<-p.buf`. Altough we have called `Stop` on the operator. This fix now closes all ports resulting in more leaked goroutines.
Codecov Report
@@ Coverage Diff @@
## master #215 +/- ##
=========================================
+ Coverage 40.99% 41.39% +0.4%
=========================================
Files 100 100
Lines 5472 5496 +24
=========================================
+ Hits 2243 2275 +32
+ Misses 3049 3043 -6
+ Partials 180 178 -2
Continue to review full report at Codecov.
|
|
@jm9e Very intresting, there race isn't fixed as it now appears randomly, where 58773ac failed, although being clean and 692f0a5 passing. I strongly belive this has something to do with sending the ´zero value´ from the closed channel to another operator. One way of moving forwared IMO would be to introduce another |
|
Don't be fooled by 6cc7c31 passing as we have seen others commits failing. It appears to me that this is a flapping test which cannot ATM be reproduced in a predictable way. |
|
@jm9e can this be merged? |
4 participants
This PR fixes all race conditions found by
-raceongo testand consequently adds-raceto the.circleci.portnow exposesmutex.Lock/Unlockportcan now detect a closed channel although this can causepanicswhen forwarding a valuegoroutinesafterop.Stop