I suspect (though I can’t prove) that it’s a mistake (i.e. wrong usage) If a thread 1/ blocks in a CondVar, 2/ unblocks by some other means, 3/ re-blocks in the same CondVar (???).
It’s probably OK to prevent that.
I wouldn’t use IdentitySet because CondVar
signalOne depends on the order of the collection. (However, here might actually be a potential use case for duplicates…? Though it still seems weird to me.)
BTW I keep saying CondVar in response to Condition because Condition is out of date. We really should deprecate it, but haven’t yet. Part of the history is that somebody tried to do timeouts by
condition.hang(aNumber), but this doesn’t really work because the timeout will fire even if the condition unblocked earlier… but it persisted for years as folklore that “we have timeouts.” IMO we should encourage the use of CondVar instead.
Agreed, there is no reason to allow that.
There’s a certain degree of unfocused speculation in this whole inquiry. It’s like a tree traversal where there are no leaf nodes – we could keep talking about this forever, and never get anything done. Would it perhaps be more productive to define the boundaries within which thread usage makes sense in SC? And then declare the rest to be wrong usage (undefined behavior, at the user’s own risk etc.).
threadPlayer exists for one purpose: to link a Routine to its owner PauseStream/Task/EventStreamPlayer. If users hijack this for other purposes, it’s wrong usage and we have no obligation to support that.
It’s nonsense for one Routine to be controlled by multiple PauseStreams. You can do it, but nobody actually does. So to some extent, this is responding to a hypothetical problem but not one that seriously impacts anyone.