-
Notifications
You must be signed in to change notification settings - Fork 31
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
Many foreign imports make sense to be unsafe imports #4
Comments
Unfortunately the very first call one makes to Vulkan ( Any See here: https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#memory-allocation
Because of this by default I think it's best to keep these as safe calls to avoid surprises. Although: I imagine that lots of users are going to just stick with the default How would be best to expose these
|
It might even make more sense to invert those alternatives and provide the unsafe functions by default, and require using alternative command or module names if one requires using Haskell callbacks. |
I like the duplicated modules. It gives users more control over scope and module qualification. I have no opinion on whether to put the |
Sounds good to me. I'll get down to closing this issue after the other issues with this package are fixed (Show instances etc...). I can't imagine that anyone's going to be requiring losing this safe call overhead for a little while yet. |
Hmm, I wonder if this could be done with a configuration flag. Along the same lines as |
I would suggest having a special flag for this. Moreover, maybe it makes sense to generalize the flag idea for something like vulkan.cabal: flag dev
description: Turn on development settings.
default: True
library
if (flag(dev))
cpp-options: -DDEVELOPMENT
ghc-options: -Wall -fwarn-tabs -O0
... *.hs: {-# Language CPP #-}
...
#if DEVELOPMENT
foreign import ccall "vkFunc" vkFunc :: Param -> IO VkResult
#else
foreign import ccall unsafe "vkFunc" vkFunc :: Param -> IO VkResult
#endif |
Well, it's not exactly a development setting. It's an optimization which is only safe to do when one hasn't given Vulkan any callbacks which could come back into Haskell-land. |
After consulting with the #vulkan channel it seems as though idiomatic usage is for development to track allocations. Seems like custom allocators are not a widely used feature anyway. |
I just made two copies of each function to let user decide if they want to play risky or not :) |
Unsafe calls are now enabled by default, they can be made safe with the |
A lot of Vulkan functions deserve unsafe bindings, for efficiency. I don't know if the spec provides enough information that the generator could figure out which ones to make unsafe automatically. Automatic or not, there are certainly some gotchas, and these are just the ones I can think of right now:
The text was updated successfully, but these errors were encountered: