|
|
|
|
|
|
|
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. |
