Minor oversight: currently awaitAll will just block forever if called on a closing or closed scope.
If the scope is closed, we should just throw an exception.
If the scope is closing, then the user is doing something weird and wrong:
- We know it's not the parent that's
awaitAll-ing, since the parent is closing the scope.
- It shouldn't be a child - calling
awaitAll really never makes sense to call from a child thread on its own scope, since it (semantically) would just block forever. So, I think we should probably just block here, waiting for the TVar to become 0, which it won't, because we'll soon get hit by a ScopeClosing.
- The third possibility, I suppose, is that the user has smuggled this
Scope away to some non-child thread that's calling awaitAll. I kind of think it's ok to again just block forever here, waiting for the TVar to become 0, which it won't. If we eventually get hit by a BlockedIndefinitelyOnSTM, then ok.
Minor oversight: currently
awaitAllwill just block forever if called on a closing or closed scope.If the scope is closed, we should just throw an exception.
If the scope is closing, then the user is doing something weird and wrong:
awaitAll-ing, since the parent is closing the scope.awaitAllreally never makes sense to call from a child thread on its own scope, since it (semantically) would just block forever. So, I think we should probably just block here, waiting for the TVar to become 0, which it won't, because we'll soon get hit by aScopeClosing.Scopeaway to some non-child thread that's callingawaitAll. I kind of think it's ok to again just block forever here, waiting for the TVar to become 0, which it won't. If we eventually get hit by aBlockedIndefinitelyOnSTM, then ok.