-
Notifications
You must be signed in to change notification settings - Fork 42
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
Exceptions 0.10.0 #61
Conversation
the previous implementation was just delegating to 'mask', and was thus interruptible
unwrap (f $ \m -> (wrap $ \s' -> io_restore (unwrap m s'))) s | ||
where | ||
wrap g = GhcT $ GHC.GhcT $ \s -> MTLAdapter (g s) | ||
unwrap m = unMTLA . GHC.unGhcT (unGhcT m) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also took the opportunity to fix the implementation of uninterruptibleMask
. It was previously defined as uninterruptibleMask = mask
, so calling uninterruptibleMask body
was misleadingly running body
in interruptible mode, not in uninterruptible mode. The difference is that some calls, like threadDelay
, are intentionally marked as being interruptible even when running inside mask
. As a result,
> timeout 1000000 $ mask_ $ threadDelay 3000000
terminates after 1 second because the timeout successfully interrupts the threadDelay after 1 second, while
> timeout 1000000 $ uninterruptibleMask_ $ threadDelay 3000000
terminates after 3 seconds, because the timeout has to wait until the uninterruptibleMask
computation terminates before aborting the computation.
Without this fix,
> timeout 1000000 $ runGhcT ... $ mask_ $ lift $ threadDelay 3000000
and
> timeout 1000000 $ runGhcT ... $ uninterruptibleMask_ $ lift $ threadDelay 3000000
both terminate after 1 second, whereas with this fix, the second terminates after 3 seconds, as desired.
(\a -> unwrap (body a) s) | ||
where | ||
wrap g = GhcT $ GHC.GhcT $ \s -> MTLAdapter (g s) | ||
unwrap m = unMTLA . GHC.unGhcT (unGhcT m) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the main fix: exceptions-0.9 introduced a new method named generalBracket
, whose type I fixed in exceptions-0.10, so in order to upgrade from exceptions-0.8 to exceptions-0.10, we have to implement this method. If we wanted, we could add an #ifdef
around this method definition in order to support both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about depending on exceptions >= 0.8.0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean >= 0.10.0, or did you change your mind and now want an #ifdef
in order to support both 0.8 and 0.10?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I indeed meant >= 0.10.0 - thanks for spotting that. I would not bother supporting 0.8 and earlier, especially given how it's a v0, and how we're likely one of the last libraries to add support for the new exceptions versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed, merging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM - I don't understand the actual change to adapt to the exceptions fix, but I trust your Haskell-fu :) Feel free to merge yourself.
Fixes #54