"Manuel M. T. Chakravarty" wrote:
> 
> Michael Hobbs <[EMAIL PROTECTED]> wrote,
> 
> > I don't think that these three FFI types are enough to cover *all* of
> > the bases regarding callbacks, blocking, and thread-safety.
> 
> My point here is that, in the RTS, "unsafe", "safe", and
> "threadsafe" is enough.  The rest is a problem of the
> libraries and library bindings.

Okay, I can agree to that. :) I thought that you were trying to make a
swiss-army-knife, which would enable one to specify every type of
behaviour that he would like a foreign function to conform to.

> Following the reverse naming scheme of the FFI paper:
> 
>   unsafe         - the RTS makes no special provisions and just
>                    calls the C function (this means the function
>                    must be well-behaved: no re-entry into the
>                    Haskell scheduler and no blocking if you
>                    don't want to block the whole Haskell system)
>   safe           - the RTS cleans things up, to allow the called
>                    function to re-enter the Haskell scheduler (but
>                    if the function blocks, the whole Haskell
>                    evaluation still blocks)
>   threadsafe     - the RTS executes the foreign call in a
>   (or supersafe)   seperate OS thread (the function can do what
>                    it likes)
> 
> The label does NOT describe a property of the function, but
> it describes the strategy of the RTS.  For "safe" calls, the
> RTS plays safe, for "threadsafe" calls it plays supersafe.
> 
> Manuel

So what you have is increasing levels of "safety"? The first one is
completely unsafe; it could royally screw up the RTS if it invoked a
Haskell callback. The second is more safe; but it may cause the entire
RTS to block. And the third is completely safe; nothing it can do will
affect the Haskell RTS (within reason). Perhaps we should have a fourth
level of safety, where it spawns a new OS process? Ha ha, only
[slightly] serious.

This works for me, as long as I can still get barrier synchronization
like we [Manuel and myself] discussed earlier, but that's another issue.
I do think that the use of the word, "safe", is unfortunate though. It
seems to be too overloaded.

- Michael Hobbs

Reply via email to