October 2002 - FFI - Haskell.org

RE: [Alastair Reid <alastair@reid-consulting-uk.ltd.uk>] Re: cvs commit: haskell-report/ffi finalizers.txt
by Simon Peyton-Jones 15 Oct '02

15 Oct '02

When it comes down to it, I don't think we are that far apart. 1. Everyone wants a C-finaliser interface; it's very convenient. So it should be in the spec. It's probably a good plan to specify that such C finalisers must obey the constraints of an 'unsafe' foreign import. 2. It is clear that GHC at least will offer a Haskell-finaliser interface, and that some people will use those Haskell finalisers; they already do. So it's desirable that they should be in the FFI spec so that there's a standard for what they look like. 3. We do not want the spec to require mutable state or concurrency, and indeed Haskell finalisers make sense (albeit are much less convincing) without such extensions. Still, I think the spec should warn explicitly that in the presence of mutable state care must be taken by the programmer, because the finaliser can run at any time wrt the "main program". 4. The spec makes no guarantees about promptness. Each implementation may want to add notes about promptness. For example, Hugs will say that C finalisers will run much more promptly than Haskell finalisers (if it supports the latter at all). I think that the only real point of difference is that Alastair would rather we did not even specify Haskell finalisers in the FFI spec, because doing so encourages non-portability. I don't agree about that; I think people will use Haskell finalizers anyway, so we should specify them. Simon

2 1

RE: [Alastair Reid <alastair@reid-consulting-uk.ltd.uk>] Re: cvs commit: haskell-report/ffi finalizers.txt
by Simon Peyton-Jones 15 Oct '02

15 Oct '02

Hi Alastair | a comment on SimonM's finalizer document. I decided to comment rather | than edit since my comments require more than tweaking the odd word | here and there. I suggest you edit directly, striving, as Simon did, to be even-handed. I do have one comment on your rejoinders, though: | I don't see how adding concurrency strengthens the argument for | Haskell finalizers. | | Adding mutable Haskell state doesn't seem to strengthen it either. | Indeed, I assume the existence of mutable Haskell state in arguing | against Haskell finalizers. Here I disagree! If you have a concurrent Haskell program, with mutable state and MVars and all, it's entirely likely that you'll have mutable state that reflects the state of the external (e.g. C) world. For example, the GHC I/O library has Haskell I/O handles that reflect the state of the underlying C handle. (For example, they contain some buffered characters as well as a C pointer to the underlying C object.) So the finaliser actually watches to the *Haskell* object; when it becomes unreachable the finaliser should run, and (amongst other things) call a suitable finaliser on the C object. But without access to the Haskell world, the finaliser can't even get hold of the C pointer to finalise! So I believe that for a non-stateful, non-concurrent Haskell program the case for Haskell finalizers is moot, it becomes much more compelling once you have state and concurrency anyway. Furthermore, Haskell finalizers then behave just like threads (which by then exist anyway) and must be treated with exactly the same care, no more and no less. Incidentally, as I understand it, it is common ground that, by scheduling finalizers on an ordinary Hugs thread, Hugs could provide Haskell finalizers exactly as GHC does. (Although that is not what Simon's patch does, I know.) The issue then becomes only one of promptness, as Simon described in the writeup. Am I right about that? Simon

2 1

Finali[zs]ers
by Simon Marlow 15 Oct '02

15 Oct '02

Thanks to everyone who has contributed to this discussion so far. Since there are a lot of subtle points to be considered at once, I thought I'd try to write a summary of the issues raised so far. I'll put something in the repository so we can all hack on it. Hopefully I'll have something ready later today. Cheers, Simon

3 4

RE: The Revenge of Finalizers
by Simon Marlow 15 Oct '02

15 Oct '02

> > However even if Haskell finalizers + MVars are impossible in NHC, I > > don't think Haskell finalizers + mutable state have to be. For > > example another mutable variable we could have would be a PVar which > > is always full and has functions [snip] > > > updatePVar (PVar ioRef) updateFn = > > do > > [stop any new finalizers running] > > a <- readIORef ioRef > > writeIORef (updateFn a) > > [reenable finalizers] > > return a > > Just for the record, I think that if we were to pursue this approach, > then the right primitive to add is: > > -- | > -- Execute argument atomically with respect to finalizers. > -- Nested calls to blockFinalizers are allowed. > -- > -- That is, while executing the argument, no finalizers will start > -- to execute. > -- (Finalizers that are already executing may continue to execute.) > blockFinalizers :: IO a -> IO a Indeed, I very nearly implemented such a thing as part of the patch I sent out. However, it didn't look trivial enough to implement so I backed off. The "blocked" state needs to be saved & restored at various points: when starting a finalizer, when invoking a foreign-exported function, and when invoking an exception handler. Cheers, Simon

4 3

[Alastair Reid <alastair@reid-consulting-uk.ltd.uk>] Re: cvs commit: haskell-report/ffi finalizers.txt
by Alastair Reid 15 Oct '02

15 Oct '02

Oops, I sent the attached document to the wrong mailing list. This is a comment on SimonM's finalizer document. I decided to comment rather than edit since my comments require more than tweaking the odd word here and there. -- Alastair Things you mights add are: eg(1) in composite finalizers: This would be handled just fine by C finalizers if addForeignPtrFinalizer guaranteed to execute finalizers in reverse order of their addition. This seems like a reasonable thing to specify since addForeignPtrFinalizer is much less useful if this guarantee doesn't hold and because it is easy to implement. eg(2): isn't too convincing since you could easily write the same thing in C. I expect you could find something more convincing with a little effort. Communicating with a foreign runtime/garbage collector: I remain unconvinced that this example has been worked out in detail and believe that if it were worked out in detail we'd either find that all George needs is to be able to call into the _runtime system_ during a Java GC (doesn't require Haskell finalizers) or that he requires a much more intimate relationship with Haskell's GC (requires a lot more than the FFI provides). Other cleanups: 1) Unsavouriness of exporting &free seems like a judgement an impartial witness would avoid. 2) Whilst "the philosophy of the FFI is to move as much marshalling machinery into Haskell as possible," the existence of an ffi suggests that foreign code does have a useful role and one could argue that finalizing foreign objects is one of those roles. Manipulating mutable state and communicating with other threads: I don't see how adding concurrency strengthens the argument for Haskell finalizers. Adding mutable Haskell state doesn't seem to strengthen it either. Indeed, I assume the existence of mutable Haskell state in arguing against Haskell finalizers. Arguments against: Adding Haskell finalizers drags in many concurrency issues for programmers: - potential to introduce race conditions - potential for deadlock As with most concurrency issues, the resulting bugs are easy to introduce, hard to reproduce and hard to track down. Adding Haskell finalizers has a high implementation burden for those who have not already implemented preemptive concurrency - greatly increasing the complexity of implementing Haskell + FFI (+ mutable state, of course - but that is a trivial thing to implement). The complexities introduced seem out of line with the problem being solved. Implementations/Hugs: You say: "There is some doubt over whether the patch is safe as it stands:" I say: "There is no doubt that the patch is unsafe as it stands:" Implications of allowing Haskell finalizers in non-concurrent systems/Mutable state: You omit my argument that, since the primary goal of finalizers is to modify mutable state, Haskell finalizers which do not modify mutable Haskell state will be of little use. All they will be able to do is lookup objects in immutable Haskell state and invoke C finalizers to do their work - a significant limitation. (In fairness, I will say that useful information might be stored in the finalizer closure so actions like looking up an object in a binary tree of all live objects (say) might be avoidable with a little effort.) Interaction with co-operative concurrency: You say (though your final paragraph suggest you don't insist on it): One might argue that since you have to do this anyway in Hugs - another thread can only get control at an explicit yield point - doing it for finalizers too isn't so bad. I say: There is a world of difference between being delayed for an unknown, finite amount of time and being delayed for an unbounded, potentially infinite amount of time. (This is why vague concepts like 'fairness' are useful in reasoning about scheduling - you don't know when you will run but you know you will get a shot sometime.) Proposals: Add: 4) No change to the spec for the time being, while we evaluate the need and cost of implementing Haskell finalizers in a range of implementations. Note that upgrading from C finalizers to Haskell finalizers would only require that we say that finalizers are invoked with the equivalent of a 'safe' ffi call instead of an 'unsafe' ffi call and, no doubt, the addition of some convenience functions. I don't think this is the same as (3)

1 0

RE: Finalizers etcetera
by Simon Marlow 14 Oct '02

14 Oct '02

> I guess the Hugs documentation should say that using unsafePerformIO > to call C which calls Haskell should be avoided. Yes it should, if such behaviour can lead to strange crashes! Better still would be to work out exactly what constraints are required on the use of eval() from primitive operations, and make sure that all the primitives comply. Then we can be sure that Haskell finalizers will work too. > I think Haskell finalizers are > different: virtually every finalizer which manipulates Haskell state > will have race conditions. This is a separate issue - which I'll wait till I've written the summary to address. Cheers, Simon

1 0

RE: Finalizers etcetera
by Simon Marlow 13 Oct '02

13 Oct '02

> > What hasn't been required is for the various data structures to be > > in a consistent state at that point, and Haskell finalizers might > > trip over those if run after GC. SimonM's patch ran them at a > > different point, though. > > It calls them in eval doesn't it? > eval is called by nearly every primitive in Hugs. > Most calls are benign since the calls are at the start of the primop > before any data structures have been fiddled with. > > It's even possible that none have any problems. All I'm saying that > we will have to look over the code before we know if there is a > problem (while others are claiming that there couldn't possibly be a > problem). Actually, I was claiming that if there's a problem there, then it's one you already have. The reasoning I used is just that eval() can call a foreign function, which can re-enter Hugs. My patch added no new code paths (as I said before). Perhaps there *are* problems with existing primitives which call eval(), but you need to check those anyway. Cheers, Simon

2 1

Finalizers strike back
by George Russell 12 Oct '02

12 Oct '02

Alastair wrote [snip] > More importantly though, this does nothing at all to guarantee > atomicity of Haskell code that manipulates global variables. Consider > a data structure consisting of a list of objects. The main thread > might add to this list and do searches in the list and the finalizer > removes objects from the list: > > type State = IORef [Object] > > -- used by main > newObject :: Object -> IO () > newObject o = do > os <- readIORef state > writeIORef state (o:os) > > -- used by finalizer > killObject :: Object -> IO () > killObject o = do > os <- readIORef state > writeIORef state (filter (/= 0) os) > > Some possible interleavings of the IO actions in these functions can > result in an object not being added to or removed from the object > list. [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. 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 the functions newObject and killObject will fail in the future should anyone try to port them to a system with pre-emptive concurrency, unless the maintainers are careful to avoid running them concurrently. So as Hugs has MVar's, I think it is bad practice not to use them here, unless you have some very good excuse (like being desperate for performance). You're basically implementing an API which has the hidden condition that the two functions must not be called simultaneously. But in any case it's somewhat woolly just to talk in terms of existing compilers. Supposing we posit that there is a GlobalVariables standard. Then indeed Alastair's example would fall over. So we can say that here is a problem which occurs with Haskell98 + FFI + GlobalVariables. However I would expect a GlobalVariables standard to specify both MVars and IORefs. The reason is precisely because of this sort of thing. Of course, as Alastair says, if all you're interested in is a single-threaded implementation, MVars seems a waste of time since either they don't block at all or they deadlock. But they *are* very necessary if you are intending to write code which may in the future be run on an implementation with full concurrency. It's precisely the same reason as why the FFI standard has a "threadsafe" keyword; although it is these days usually unnecessary, it is nevertheless very important to have it there because of what might happen in the future. So I can sum this up by saying (1) a GlobalVariables standard should specify both MVars and IORefs. (2) Someone writing finalizers on a Haskell98 + FFI + GlobalVariables implementation would have absolutely no excuse for using code such as that Alastair has given, since this is a really blinding example of where MVars are needed. 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. This is much better than expecting them to rely on arcana such as the details of Hugs scheduling strategy. In any case I disagree with Alastair when he says bugs of this sort are as bad as bugs caused by calling Haskell from a finalizer in Hugs. At least in this case Haskell's RTS is still healthy. Assuming the crash comes reasonably often, you can narrow it down by putting in loads of print statements, until eventually you get to the stage of asking "Who put what into the State variable". Not very pleasant, but you will get there. However if I understand it correctly, calling Haskell from a finalizer under the FFI may lead to nothing but a core-dump. Furthermore print statements will not help you because the finalizer might have been called anywhere; at the best you will only find out where the GC happened. Even if you guess that the reason Haskell's RTS blew up at just that point was because of a rogue finalizer during which an external Haskell function happened to be called, you have no way in Haskell of finding out what that finalizer might be, even less of finding out what external Haskell function the outside world was trying to invoke.

4 10

RE: Finalizers etcetera
by Simon Peyton-Jones 12 Oct '02

12 Oct '02

| I claim that the major thing that finalizers do is manipulate shared | state. That is certainly true. If they were pure, you'd never know they'd run! | To get any benefit from writing finalizers in Haskell, I have to have | MVars which protect against finalizers. Nearly right, but not quite. You might write a Haskell finalizer that did lots of useful things (e.g. consulted a large pure data structure) before doing its state-mutation by calling C. | > And if they existed, everything would be fine, right? We could | > just use Haskell finalizers as we all want. Or am I missing | > something. | | Finalizers would have to be scheduled by the same scheduler as normal | threads. Yes. | The scheduler would need to prioritize finalizers over normal threads. Desirable but not necessary. The programmer cannot expect finalizers to run promptly (there is always lots of literature on the GC mailing list about this point). | Most of the cooperative concurrency implementation is written in | Haskell. That would have to be rewritten in C to make the operations | atomic wrt garbage collection. No, I disagree with this. When GC runs, the finalizers can be put in the ready queue. After GC completes, the thread that was interrupted by GC continues. So a thread switch takes place ONLY when the thread yields, as now. (Again, promptness is not a reqt. If the thread never yields, the finaliser will never run. That is 100% ok. You absolutely should not RELY on finalizers. So the question before the house is to choose between: A) Haskell finalizers: flexible; continue to be what we want when we have concurrency; but if your impl does not support MVars you have to call C to do state mutation. B) C finalizers: less flexible; GHC will have (A) anyway; but arguably one less trap for the unwary. I still prefer (A), albeit not unto death, because (i) I believe that supporting MVars in Hugs is not as hard as you think. (I'm agnostic about NHC.) (ii) Less incompatibility... (i.e. programs that use GHC extensions that won't run on Hugs) (iii) Moves in the direction we will ultimately want to go. It seems bizarre to write finalizers in a different language! Simon

3 2

RE: Finalizers etcetera
by Simon Peyton-Jones 11 Oct '02

11 Oct '02

| (a) It was the first mention of MVars that I found in the docs. | (b) I only really mentioned it because the type sigs are wrong. Hmm. That's not very clever. | Doesn't it block if another thread manages to sneak a putMVar into | the middle? Maybe I should read your "Awkward Squad" paper to find | out if this matters. Yes it does block if another thread sneaks in a put. If it matters, you'd better code up a more robust abstraction (using MVars of course). S

1 0