Use resourcet for resource managment #675
Conversation
| r <- runDelayed rawApplication env request cleanupRef | ||
| go r request respond `finally` runCleanup cleanupRef | ||
| r <- runDelayed rawApplication env request | ||
| go r request respond |
There was a problem hiding this comment.
wait, here I guess I'll run cleanups too early. Wouldn't it?
| @@ -264,18 +303,17 @@ passToServer Delayed{..} x = | |||
| runDelayed :: Delayed env a | |||
| -> env | |||
| -> Request | |||
| -> CleanupRef | |||
| -> IO (RouteResult a) | |||
There was a problem hiding this comment.
so should this return ResourceT IO (RouteResult a)?
| @@ -65,7 +63,7 @@ steps: | |||
|
|
|||
| # A common setting is the number of columns (parts of) code will be wrapped | |||
| # to. Different steps take this into account. Default: 80. | |||
| columns: 80 | |||
| columns: 120 | |||
There was a problem hiding this comment.
not really, except with current style the import lists are almost always spanning multiple lines, which I find annoying. There's a bit of settings in newest stylish-haskell so if the line is too long, imports could be aligned as
import Data.List (foldl')
import qualified VeryLongNamespace.Data.Foo.Bar
(foo, bar, quux, longMethodName, anotherLongMethodName, Foobar,
MonadEveryhing, zyxxy)or at least I remember making some such configuration possible.
I'll revert this change and investigate more (subjectively) pleasant (yet diff friendly) formatting style.
| instance MonadThrow m => MonadThrow (RouteResultT m) where | ||
| throwM = lift . throwM | ||
|
|
||
| -- instance MonadCatch m => MonadCatch (RouteResultT m) where |
| newtype RouteResultT m a = RouteResultT { runRouteResultT :: m (RouteResult a) } | ||
| deriving (Functor) | ||
|
|
||
| -- As we write these instances, we get instances for `DelayedIO` with GND. |
There was a problem hiding this comment.
I don't think the comment is necessary. Instances are always good in my opinion.
| pure = return | ||
| (<*>) = ap | ||
| returnRouteResult :: RouteResult a -> DelayedIO a | ||
| returnRouteResult x = DelayedIO $ lift . lift $ RouteResultT . return $ x |
There was a problem hiding this comment.
Not sure about the name, but can't think of anything better (maybe delayRouteResult?)
There was a problem hiding this comment.
What's about liftRouteResult ?
| it "writes and cleanups resources" $ do | ||
| request "GET" "foobar" [] "" `shouldRespondWith` "foobar" | ||
| liftIO $ do | ||
| cleanUpDone <- isJust <$> readIORef delayedTestRef |
There was a problem hiding this comment.
This test can in theory pass if check in line 67 were never run. Can we maybe write something other than Nothing (the initial ref state) to be sure the value is coming from deallocation?
There was a problem hiding this comment.
I'll make a IORef three way, None | InUse a | Cleared.
|
|
||
| ------------------------------------------------------------------------------- | ||
| -- Spec | ||
| ------------------------------------------------------------------------------- |
There was a problem hiding this comment.
I definitely don't insist on it, but it perhaps would be nice to have a test where the combinator allocating the resource forks a thread, and that thread waits on an MVar (with readMVar). Then the test checks (a) that before it putMVars, the resource is not yet deallocated, and (b) after it putMVars, the resource is deallocated.
What I have in mind is forking jobs that are longer running, which I imagine would be commonly used in conjunction with resources, especially if we make Handler a MonadResource.
There was a problem hiding this comment.
I'm not understand, could you write an example, assuming that Handler is MonadResource?
| runDelayedIO | ||
| (do c <- capturesD env | ||
| methodD | ||
| a <- authD | ||
| b <- bodyD | ||
| DelayedIO $ \ r _cleanup -> return (serverD c a b r) | ||
| r <- ask | ||
| returnRouteResult (serverD c a b r) |
There was a problem hiding this comment.
Now that Handler is abstract, and that this is being added, I feel like it makes sense to make Handler a MonadResource so that handlers can also register, allocate, and release. That said, that can just as well be a separate PR.
There was a problem hiding this comment.
Handler cannot, it's just ExceptT ServerErr IO a. Then we'll need to add ResourceT there too. I'm neutral about that.
There was a problem hiding this comment.
(There's no technical problem adding it, the runHandler is inside runResourceT anyway).
No description provided.