> [snip] I'm not sure I really understand the problem. The FFI > standard (Release Candidate 4, the one I have printed out here) does > not define IORefs, and of course Haskell 98 doesn't either. > Therefore, although this code is broken, this particular example > doesn't matter if all we are considering is code written in Haskell > 98 + FFI.
If there's no shared mutable Haskell state, writing finalizers in Haskell buys you little - what does a finalizer do other than cleanup shared state? (Note that it doesn't cleanup unshared state - what would be the point?) I think IORefs are the most widely accepted extension of Haskell. The FFI spec doesn't depend on IORefs but it should certainly be designed to work in an environment where they exist. > However to me this code just looks totally wrong because of course I > use GHC, a system with preemptive scheduling, and would regard it as > incompetent to use anything other than an MVar here. I completely agree. I do not believe we can have any useful form of Haskell finalizers (meaning finalizers that manipulate shared Haskell state) without adding MVars. But, since concurrency is not so widely implemented as IORefs, we are trying to produce an FFI design which does not require concurrency extensions. My solution to this conflict is not to add Haskell finalizers. > However to me this code just looks totally wrong because of course I > use GHC, a system with preemptive scheduling, and would regard it as > incompetent to use anything other than an MVar here. Even for Hugs > I don't like this code, because [...] I think you're taking my code out of context. The purpose in writing that code using IORefs was to show the kind of code you should not write because it would suffer from race conditions. I completely agree that some form of locking is required to make the code safe. I guess I'd be willing to have Haskell finalizers if we agreed on an appropriate form of locking that all implementers can and will implement. NHC currently lacks a locking mechanism. I believe that using Hugs' MVars in conjunction with SimonM's patch will lead to deadlock in the cases that would have suffered race conditions using IORefs. > Supposing we posit that there is a GlobalVariables standard. Just want to remark that the variables don't have to be global. Haskell finalizers are specified by closures and closures can point to any IORefs you fancy. > Anyone writing a finalizer should be aware (indeed the FFI standard > should say) that the finalizer may be run at any point (after all, > when else would you expect it to run) and should take precautions > against it. What I hear you saying is that the FFI standard should depend on a concurrency standard. I think there was a strong sentiment that we should avoid this. I agree though that it is necessary if we allow Haskell finalizers. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi