Process : Fix exception handling in acquireCollaborativeResult()
#5529
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When an exception was thrown from
ProcessType::run()
, we were catching it and rethrowing it from the code path that initiated the collaboration. But since we were rethrowing after therun_and_wait()
, collaborating threads could leave theirwait()
before the exception was rethrown. In this case, they would throw their own vague exception about there being no result available, and this exception could be the first thrown, and therefore the first one to surface back to the caller. We now store the original exception inTypedCollaboration::result
(now a variant) so that both the initiator and the collaborator throw the same exception.Technically this is an ABI break, because it changes a member in TypedCollaboration. But for it to cause a problem, the following conditions would need to be met :
acquireCollaborativeResult()
already. I'm not aware of anyone ever creating their own Process subclass, so the chances of someone doing that and using a new feature that was only released yesterday are vanishingly small.I think it's pretty clear that the lesser evil in this case is to fix the bug.