Changes between Version 1 and Version 2 of ForeignBlocking

Mar 30, 2006 2:03:28 PM (9 years ago)



  • ForeignBlocking

    v1 v2  
    1 Even though we most likely won't want to make concurrency part of the 
    2 language. perhaps we should consider adding thread annotations to the 
    3 FFI spec now, so that C bindings with thread annotations can be portable 
    4 (even if they don't actually make use of concurrency). 
     1= Background = 
    6 Now, if I understand the situation with ghc, it has two ways of binding 
    7 something 
     3In the FFI, there are two ways to annotate a foreign call: 
    9 safe - might block, might call back into the haskell runtime 
    10 unsafe - won't block, won't call back into the haskell runtime. 
     5  * '''safe''' (the default).  This means the foreign call can invoke a foreign export, 
     6    and hence re-enter Haskell. 
    12 while this is fine for ghc, I was hoping we could separate out the 
    13 mechanisms of whether a routine will block and whether it is "safe". 
     8  * '''unsafe'''.  The programmer guarantees that the foreign call cannot re-enter Haskell, 
     9    and the implementation may use this information to optimize the call. 
    15 so, I suggest we keep 'safe' and 'unsafe' as they are in the report, and 
    16 add 'blockable' meaning the routine might block indefinitly and if the 
    17 implementation uses concurrency then it should take efforts to ensure it 
    18 does not block the whole runtime. 
     11Additionally in GHC, "safe" means that the call should not prevent other Haskell threads from making progress.  It indicates a ''concurrent foreign call'' (see [wiki:Concurrency]). 
    20 in particular, the common case of 'blockable unsafe' can be implemented 
    21 particularly simply compared to 'blockable safe' since we only need to 
    22 spawn off a pthread for the routine and have it write a status byte to a 
    23 pipe when done that can be handled via the standard select mechanism of 
    24 an implementation. 
     13If the standard is to include concurrency, then it is a significant burden to include the full functionality of "safe" foreign calls as implemented by GHC as a requirement.  It would imply that the runtime must be able to handle multi-threaded call-in, that is, call-ins from multiple OS threads simultaneously.  In contrast, if the implementation only has to handle call-ins that occur during a synchrounous call-out, the implementation is much simpler. 
    26 so, in any case, the point of adding it to the standard is so that 
    27 everyone can annotate their functions 'blockable' and implementations 
    28 without concurrency will know to ignore it and not die with an error. 
     15= Proposal = 
    30 for GHC it would be as simple as just treating 'blockable' as implying 
    31 'safe' and perhaps someone could implement 'blockable unsafe' for ghc 
    32 someday so that it won't require -threaded for (many? all?) blockable 
    33 routines. 
     17There are simpler positions that can be adopted that reduce the requirements on the implementation.  The current proposal is this: 
     19  * '''concurrent''' indicates a foreign call that runs concurrently with other running Haskell threads. 
     21  * '''nonreentrant''' ('''pure''' has also been suggested) indicates that the foreign call does not invoke 
     22    and Haskell code. 
     24and the standard would only require that concurrent is supported with nonreentrant; concurrent alone is an extension.  The standard would also clarify that multi-threaded call-in is not a requirement.