October 2002 - FFI - Haskell.org

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

11 Oct '02

| Am I right in thinking that you are proposing that we revert to | writing Haskell finalizers but that Hugs and NHC programmers would | have to avoid writing finalizers which manipulate Haskell state while | GHC would use MVars to protect that state? Yes, that's right. It is often the case that there *is* no shared state so a Haskell finalizer is fine. But if there is, then there has to be some mechanism for atomic operations. C is one such mechanism. But there's something I'm puzzled about. Hugs does support non-pre-emptive concurrency, right? (Where can I find a description of it.) So would it not be easy to implement (non-pre-emptive) MVars? And if they existed, everything would be fine, right? We could just use Haskell finalizers as we all want. Or am I missing something. (I'm assuming that the starting point for the entire discussion is whether finalizers are written in Haskell or C. Please let me know if I missed something.) Simon

3 3

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

11 Oct '02

| type MVar# s elt -- primitive | | newMVar# :: State# s -> (# State# s, MVar# s elt #) | takeMVar# :: SynchVar# s elt -> State# s -> (# State# s, elt #) | putMVar# :: SynchVar# s elt -> State# s -> State# s Bad idea to look at the primops. The important things are the MVar type the operations newMVar, takeMVar, putMVar the forkIO operation Their semantics are described (completely I think) in my "Tackling the awkward squad" tutorial. | As another aside, in the hierarchical libraries docs (package base, | Control.Concurrent.MVar) there appears to be an ambiguity: | | readMVar :: MVar a -> IO a | This is a combination of takeMVar and putMVar; ie. it takes the | value from the MVar, puts it back, and also returns it. | | It specifically avoids describing the combination as atomic, so I | am uncertain whether the thread can be pre-empted between the 'take' | and the 'put'? Normally the answer would be yes, but then there is no | benefit from having a separate 'readMVar' to combine the operations, | so I am guessing that it /should/ be atomic. False. readMVar is completely described by readMVar m = do { v <- takeMVar m; putMVar m v; return v } If it gets pre-empted between the take and the put, no matter; anyone trying to take from that same MVar will block. Simon

2 1

Low Price Smokes
by Sales Department 11 Oct '02

11 Oct '02

Dear Sir or Madam In the past you have requested information on discounted products. If you are not a smoker, and find this email offensive, then we sincerely apologise. We will be only too happy to take you off our database. If you are a smoker, however, you are probably fed up with paying high prices for your cigarettes and tobacco. Take a look at what we can do for you at http://www.smokersassociation.co.uk/?S=23&ID=2 We can send you, legally, by registered air mail, direct to your door, 4 cartons of cigarettes or 40 pouches of rolling tobacco (all brands are available) from only 170 Euros - about 105 pounds - fully inclusive of postage and packing. Why pay more? If you would rather not hear from us any more, this link will ensure that you are not bothered again. mailto:unsubscribe@smokersassociation.co.uk Yours faithfully. Smokers Association http://www.smokersassociation.co.uk/?S=23&ID=2 xay9496901y

1 0

Finalizers etcetera
by George Russell 10 Oct '02

10 Oct '02

In fairness I should state that here at Bremen we do not currently need Haskell finalizers. I was thinking of another application altogether, but I don't particularly want to go into details of that. There are however particular reasons (such as galloping concurrency) why I think Alastair's proposed hooks would be impractical in that case, even if they were provided by both garbage collectors, which they wouldn't be. I don't think we are coming any nearer to a solution on this. There seem to be three proposals: (1) Alastair's: keep the signature as it is, with the restriction. Add miscellaneous hooks allowing C to do things to the Haskell world without actually entering it. (2) Mine: keep the signature as it is, but remove the restriction, at least so that if implementations decide to impose the restriction anyway, they have to document it very clearly. (EG "Hugs implements the FFI standard [ref]" with the restriction that finalizers may not call back into Haskell (see paragraph [whatever]"). (3) Manuel's: reverse the change altogether. Ideally I'd like Manuel's solution, except that we obviously can't force Hugs and NHC to comply with it. I think therefore I prefer my solution in that it makes clear you can write simple portable FFI code which runs on any implementation with or without the restriction, but non-trivial use involving interaction with foreign garbage collectors and the like is likely to fall over. I don't deny that it is likely to be possible to write non-trivial applications involving finalizers in several languages even in Hugs, but you will have to provide various hooks which are in general quite inappropriate. Other choices might be some kind of lock which could be operated from both the Haskell and C world (since then it would be possible, painfully, for a C finalizer to arrange for a Haskell thread sleeping on the lock to wake up, if enough scheduling points arise). Or as Alastair suggested, you can at least arrange for some Haskell functions, like freeStablePtr, to be made available in the C world. Such things might be a good idea in Hugs or NHC (obviously it's not for me to say), if Haskell finalizers really are impossible. But in general I think it is simply absolutely inappropriate for such solutions to be specified in the standard, since they seem to assume too much and impose too much work on the user, if the user is happy to use GHC.

4 9

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

10 Oct '02

Alastair, You didn't respond to my proposal, perhaps because it didn't seem like one (I've changed a few words) | a) Haskell finalisers should be available on all systems | | b) Finalisers can run at any GC point. The programmer needs to be aware | of this. Often it does not matter (e.g. calling 'free' to un-malloc | some space) but sometimes it does. | | c) On systems (like Hugs and NHC) that have no way to builds uninterruptible | sequences, you have to roll your own by calling C procedures. This is easy to specify and easy to implement. It frees stuff promptly (just after GC). The down-side is that if you are careless you can write stuff that mutates an IORef that is simultaneously mutated by a finaliser. In GHC you solve this with MVars. In Hugs you solve this by writing it in C. But either way, full Haskell is available for finalisers, and we have the nice simple interface that we all want. I feel I must be missing something. Simon

3 2

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

09 Oct '02

| > c) On systems (like Hugs and NHC) that have no synchronisation | > primitives, you have to roll your own by calling C procedures. | | Just to be clear about this. | | You are not rolling your own synchronization primitive, you are | writing code that is guaranteed to contain no preemption points | because it does not call Haskell. Yes, you're right. I should have said that. Simon

1 0

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

09 Oct '02

| > (A mutex lock is required to ensure that the pending queue is not | > traversed more than once, but that is all I think.) | | I don't understand how this would work in single-threaded systems (like | I understand NHC to be). I haven't been following the details of this discussion, but I think there may be some confusion. 1. I think we all now agree that it's easy to arrange to run finalisers at the end of GC, not during GC, by putting them on a queue and running them after GC. But as recently as 27 Sept we didn't agree because when Ross suggested that a Haskell finaliser could call a C function, Alastair replied: | That would have the garbage collector invoking a C function (this is | ok) which then calls a Haskell function (this is not and the ffi spec | says not to expect it to work). Still, I think we now agree that this is fine. 2. The end of GC is by definition a yield point in the original program; that is, a point where it is prepared to do GC. 3. Alastair's point is that a GC-yield point might not be a safe place to run a finaliser. His example is: the main program maintains a list of active windows in a mutable location the finaliser removes an item from that list He is absolutely right about this. 4. I believe that the alternative Alastair advocates is to make finalisers run in C only. Why does that solve the problem? Because that would force the mutable list of windows (in the example) to be implemented in C, and that in turn means that manipulating the list is indivisible. Conclusion: finalisers in C is simply a way of performing atomic operations. The obvious conclusions from this are as follows a) Haskell finalisers are available on all systems b) Finalisers can run at any GC point. The programmer needs to be aware of this. Often it does not matter (e.g. calling 'free' to un-malloc some space) but sometimes it does. c) On systems (like Hugs and NHC) that have no synchronisation primitives, you have to roll your own by calling C procedures. I like this because it exposes what the real issue is without imposing a single solution. Simon

2 1

ADV: Website Promotion
by peter12＠arabia.com 08 Oct '02

08 Oct '02

*To be removed see below. Greetings, I work with a company that submits websites to search engines and saw your listing on the Internet. We can submit your website to over 300 of the worlds best search engines and directories for a one time charge of only $39.95. If you would like to put your website into the fast lane and receive more Internet traffic call our toll-free number (877) 284-8258. All work is verified! Sincerely, Peter Murphy ________________________________________________________________________________________________________________________________________________ *To be removed call toll free: (888) 529-1703 2788CrjK4-778GpBE1969hYGi2-117Kzxm1932NEoh8-505XuOq5417zvZh0-911GkTx5l65

1 0

ADV: Website Promotion
by peter12＠arabia.com 08 Oct '02

08 Oct '02

*To be removed see below. Greetings, I work with a company that submits websites to search engines and saw your listing on the Internet. We can submit your website to over 300 of the worlds best search engines and directories for a one time charge of only $39.95. If you would like to put your website into the fast lane and receive more Internet traffic call our toll-free number (877) 284-8258. All work is verified! Sincerely, Peter Murphy ________________________________________________________________________________________________________________________________________________ *To be removed call toll free: (888) 529-1703 3691zQXE0-340refm5306GQtu0-85l27

1 0

ADV:Website Promotion
by peter12＠arabia.com 08 Oct '02

08 Oct '02

*To be removed see below. Greetings, I work with a company that submits websites to search engines and saw your listing on the Internet. We can submit your website to over 300 of the worlds best search engines and directories for a one time fee of $39.95. If you would like to put your website into the fast lane and receive more Internet traffic call our toll-free number (887) 284-8258. All work is verified! Regards, Peter Murphy __________________________________________________________________________________ To be removed call toll-free: (888) 529-1703 4173oxwW1-376JAzl15

1 0