Skip to content
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

How would one use dejafu with safe-exceptions or unliftio? #298

Open
robinp opened this issue Mar 14, 2019 · 3 comments
Open

How would one use dejafu with safe-exceptions or unliftio? #298

robinp opened this issue Mar 14, 2019 · 3 comments

Comments

@robinp
Copy link

robinp commented Mar 14, 2019

Those libs are getting some traction. I wonder if it is possible to run dejafu against those? Also, would it be able to take into account the different behavior of exception handling primitives (regarding using uninterruptibleMask in cleanup for example)?

@barrucadu
Copy link
Owner

safe-exceptions uses the typeclasses from the exceptions library, which dejafu also uses, so I think all the safe-exceptions functionality will just work, except for:

  • throwTo - because it uses Control.Exception.throwTo
  • catching exceptions thrown by assert or impureThrow - because they use primitive IO exception mechanisms

Though if you've got any examples where dejafu doesn't work, I'd be interested to see them.

unliftio is trickier, because its whole idea is to run things in IO, eg UnliftIO.Concurrent.forkIO is

forkIO :: MonadUnliftIO m => m () -> m ThreadId
forkIO m = withRunInIO $ \run -> C.forkIO $ run m

Where that C is Control.Concurrent. dejafu is based on abstracting over IO, because we can't inspect IO actions. I don't have a good answer for how unliftio could be handled, yet.

Also, would it be able to take into account the different behavior of exception handling primitives (regarding using uninterruptibleMask in cleanup for example)?

I'm not sure what you mean.

@robinp
Copy link
Author

robinp commented Mar 19, 2019

Thanks for clarifying safe-exception usage. I had in mind the different constraint on say onException (MonadCatch vs MonadMask), but if dejafu is coded against those as well then fine.

For unliftio, could one bridge the constraints from concurrency with that from unliftio?

@barrucadu
Copy link
Owner

For unliftio, could one bridge the constraints from concurrency with that from unliftio?

You could certainly make a type which is an instance of both concurrency and unliftio (well, I don't see any immediate reasons why not), but I'm pretty sure the Program type which dejafu uses for testing can't be given a lawful MonadUnliftIO instance, because there's continuations and state involved. So in practice you wouldn't be able to test with dejafu something of type (MonadConc m, MonadUnliftIO m) => m a.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants