-
Notifications
You must be signed in to change notification settings - Fork 32
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
Add resource managing bindings #49
Comments
Having another monad can be problematic w.r.t. composition with users' "application" stack. Perhaps it would be better to have not one resource library, but many - one for each composition style. |
That's exactly the plan :) I've written a small bit of TH towards this goal: https://hackage.haskell.org/package/autoapply To generate these libraries would just involve mirroring the module tree and adding on It would be nice to have multiple public libraries in this package to accomplish this, but support on Hackage isn't forthcoming... Hopefully I recently (not released on hackage yet) changed the types of the "bracketing" functions so that they don't rely on bracket directly: 6ad4598#diff-7b4f6f44bc221c0556d3d6faed15fc51 This allows them to be more easily used with any resource allocation scheme. |
I kinda like how bracket-arguments are working but find it too easy to leak resources. Sometimes I need resources to stay across the entire program run, but sometimes those are scratch buffers and other transient things. One misplaced |
I think this is more a problem with Haskell's overall clumsy/verbose handling of scarce resources rather than with autoapply. After all, it's just writing boilerplate for you. I do see the problem though, so here are a few potential solutions:
As an aside, one thing I've encountered is freeing resources (after an exception is thrown) while command buffers are still in flight, the validation layers gets angry about destroying things which are still in use. I don't think it would be appropriate to wait for the device to become idle in such a case... |
I wonder if it would be worth moving the continuation to the last parameter, so one could do foo = withInstance zero Nothing $ \c d -> do
-- Create instance
i <- c
-- use instance
...
-- Destroy instance
d i |
I've thought about this quite a few times too. |
Cool, I'll make the change then :) |
I bump frequently into resource <- createStuff bracket (zero { stuff = [] }) Nothing I don't know if that would be a good change for managed bindings, but I think I'd like having For example: createResource boi ler plate createInfo callback = ...
myResource = createResource boi ler plate
theMyResource = myResource zero { base = mine }
things =
theMyResource $ \one ->
theMyResource $ \two ->
... This should make |
Yeah, that was exactly the reason it was the first argument initially. It's no big deal to move it back to the front. For continuations though they do feel more at home as the last argument IMO. -- Not sure why you'd want to do this, but it can be done (or something like it)
foo = do
(c, d) <- ContT . (.curry) $ withInstance zero Nothing
... The change for the examples in the repo weren't too painful FWIW 1754222 |
The more I think about it, the less appropriate vanilla Perhaps something like this would be good: foo = do
-- Allocate a resource
(myReleaseKey, myResource) <- withResource ...
-- Record a command buffer using myResource
commandBuffer <- recordMyCommandBuffer myResource
(myFenceReleaseKey, myFence) <- withFence ...
mask $ \_ -> do
queueSubmit commandBuffer myFence
traverse_ (addFenceToResource myFence) [myReleaseKey, ...]
addFenceToResource fence releaseKey = mask $ \_ -> do
Just free <- unprotect releaseKey
register $ do
waitForFence fence
free It would be cool to do automatic tracking of resources being used in commands, but I do think that is out of scope for these bindings. Doing something like the above does seem like a whole can of worms though, might just be more simple to |
Now that Hackage supports cabal v3 (haskell/hackage-server#852) resource management bindings for specific libraries could be put into publicly visible sublibraries |
@dpwiz I don't much mind where the continuation parameter goes (first or last), just to summarize:
|
I have a feeling that CPS-style would compose better. And that's more important for a lower-level bindings. Frameworks can put on their gloss later in whatever style they prefer. |
Sounds good to me, I'll merge then
…On Tue, May 5, 2020, 1:17 AM Alexander Bondarenko ***@***.***> wrote:
I have a feeling that CPS-style would compose better. And that's more
important for a lower-level bindings. Frameworks can put on their gloss
later in whatever style they prefer.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGRJXD7MVHOEJUPTG6PW73RP3Z6PANCNFSM4LZESPIA>
.
|
BTW, I started a ground-up rewrite of my tutorial scene into RIO-based playground. The main theme was to split allocated stuff into three groups:
The stages demarcated by I hesitated using It still doesn't draw a thing 😅 so I don't know how slow it is. |
@dpwiz very cool, Please add a link to the readme if you think it'd be a good example for people looking to use this library. I've started on a nicer example on the |
I've seen "resize" code and it is. so. much. nicer. to have all the stuff in separate modules. This, or maybe I just got more experienced in it with time (= |
Having played with |
Yeah, I'm very happy with how autoapplyDecs
(<> "'") -- Suffix a ' to make new names
[ 'getDevice -- = MonadVulkan m => m Device
, 'getInstance
, 'getAllocator
, 'noAllocationCallbacks -- = Nothing :: Maybe AllocationCallbacks
]
-- 'Control.Monad.ResourceT.allocate' doesn't subsume the continuation type on the "with" commands, so
-- put it in the unifying group.
['allocate]
[ 'deviceWaitIdle
, 'getDeviceQueue
, 'withInstance
, 'cmdDraw
, ...
] |
It would be nice to have bracket functions which used
ResourceT
,Managed
orPolysemy.Resource
to manage resources. These really shouldn't be too hard to generate, but probably shouldn't go in the main library. I guess while we're here we could also do bindings lifted intoMonadIO
The procedure would be, for each module with bracket commands in to write a new module reexporting all but the bracketed commands, as well as the differently typed bracketing command.
It would also be necessary to do the parent modules too, so one could just import
Graphics.Vulkan.Core10.ResourceT
to get everything but the brackets fromGraphics.Vulkan.Core10
as well as the new bracket functions.Might also be nice to have a
Vulkan
monad which carries around the instance and device, as well as a separate monad forcmd
s.The text was updated successfully, but these errors were encountered: