-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modifyMVar and modifyMVar_ exceptional behavior looks off #4
Comments
treeowl
added a commit
to treeowl/strict-concurrency
that referenced
this issue
Jan 15, 2019
treeowl
added a commit
to treeowl/strict-concurrency
that referenced
this issue
Jan 15, 2019
treeowl
added a commit
to treeowl/strict-concurrency
that referenced
this issue
Jan 15, 2019
treeowl
added a commit
to treeowl/strict-concurrency
that referenced
this issue
Jan 15, 2019
treeowl
added a commit
to treeowl/strict-concurrency
that referenced
this issue
Jan 15, 2019
treeowl
added a commit
to treeowl/strict-concurrency
that referenced
this issue
Jan 15, 2019
treeowl
added a commit
to treeowl/strict-concurrency
that referenced
this issue
Jan 16, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In case of an exception,
modifyMVar
andmodifyMVar_
use the strictputMVar
to try to restore theMVar
contents. This can itself throw an exception or fail to terminate, preventing the contents from being restored. I'm quite confident they should use the version fromControl.Concurrent.MVar
in the exception handler.The text was updated successfully, but these errors were encountered: