|Version 1 (modified by john@…, 9 years ago) (diff)|
Even though we most likely won't want to make concurrency part of the language. perhaps we should consider adding thread annotations to the FFI spec now, so that C bindings with thread annotations can be portable (even if they don't actually make use of concurrency).
Now, if I understand the situation with ghc, it has two ways of binding something
safe - might block, might call back into the haskell runtime unsafe - won't block, won't call back into the haskell runtime.
while this is fine for ghc, I was hoping we could separate out the mechanisms of whether a routine will block and whether it is "safe".
so, I suggest we keep 'safe' and 'unsafe' as they are in the report, and add 'blockable' meaning the routine might block indefinitly and if the implementation uses concurrency then it should take efforts to ensure it does not block the whole runtime.
in particular, the common case of 'blockable unsafe' can be implemented particularly simply compared to 'blockable safe' since we only need to spawn off a pthread for the routine and have it write a status byte to a pipe when done that can be handled via the standard select mechanism of an implementation.
so, in any case, the point of adding it to the standard is so that everyone can annotate their functions 'blockable' and implementations without concurrency will know to ignore it and not die with an error.
for GHC it would be as simple as just treating 'blockable' as implying 'safe' and perhaps someone could implement 'blockable unsafe' for ghc someday so that it won't require -threaded for (many? all?) blockable routines.