October 2002 - FFI - Haskell.org

Finalizers: conclusion?
by Simon Marlow 24 Jan '03

24 Jan '03

Ok, I'm sad to say that the problem we recently uncovered to do with finalizers sharing values with the rest of the program essentially kills off the possibility of doing Haskell finalizers in systems without proper concurrency support. I'm rather embarassed that I didn't notice this before; sorry for wasting everyone's time :-( Let's keep C finalizers for the FFI spec. In GHC I imagine we'll continue to offer Haskell finalizers as an extension, but I haven't decided on an interface yet (suggestions welcome). >From now on I intend to keep track of a strict quota that prevents me from writing more email than code :-) Cheers, Simon

6 8

RE: addForeignPtrFinalizer
by Simon Marlow 26 Nov '02

26 Nov '02

> > Actually in the current implementation the finalizers are not > > attached to the ForeignPtr at all: it's the other way around. > > Ah, I see. > > Fortunately, I don't think my sketched implementation depended on such > an attachment since it added an attachment of its own. The design is > intended to sit on top of the current GHC implementation (i.e., one > with Haskell finalizers and no control over the order they are run). Yes, you're right. We could do it that way. I'm also concerned about adding the extra overhead though, especially if this is something that will rarely be needed. Are we sure this is what we want? At least I can optimise mallocForeignPtr again and avoid registering the finalizer until the first call to addForeignPtrFinalizer. Cheers, Simon

3 4

RE: ForeignDependencies: The Semantics
by Simon Marlow 26 Nov '02

26 Nov '02

> ack! no with my intended semantics, cycles are not a problem anymore > than they are for weak pointers or the touchForeignPtr method. > everything will still be GCed just like normal. > > (note that these are pretty much exactly the Weak Pointer > semantics, if > you like replace 'ForeignDependency' with Weak Pointer as you read and > it should make sense) > > addForeignDependency k v creates a weak pointer from k to v. a weak > pointer ONLY affects GCing and guarantees __nothing about the > ordering of > the finalizers__ for the key and value (I will show why this is not a > problem). Thanks for the summary John. Actually this is the conclusion that Simon & I came to about 2 minutes ago, without reading your message. We need to be very clear about the difference between what you're proposing and a stronger requirement on finalizer ordering. In particular, in your example, if the finalizer for k actually follows the pointer to v, then you really need finalizer ordering and just liveness dependencies won't do. The GHC team's view is that we can implement finalizer dependencies pretty easily (with weak pointers, of course), but doing finalizer ordering is another kettle of fish altogether. We think it's better to steer well clear if at all possible, but the methods I outlined in my previous message still apply (I think ordering finalizers placed on the same object with addForeignPtrFinalizer is probably ok, and I'll implement it in GHC when all this has settled down). For Hugs & NHC, it would probably suffice to keep a list of dependencies in the ForeignPtr. After GC, you have to repeatedly traverse the live ForeignPtrs making each of the dependencies live, until you can make no more ForeignPtrs live, then finalize the dead ones. Cheers, Simon

2 2

RE: location of HsFFI.h?
by Simon Marlow 30 Oct '02

30 Oct '02

> On Wed, Oct 30, 2002 at 09:12:01AM -0000, Simon Marlow wrote: > > If this isn't possible, then you can extract the > information from the > > output of 'ghc -v'. The relevant directory is in the > include_dirs field > > of the rts package. > > michaelw@stargate:~$ ghc --print-libdir > /usr/lib/ghc-5.04.2 > michaelw@stargate:~$ Thanks, I forgot I'd added that flag :-) > so: > > GHC_INCLUDES := $(shell ghc --print-libdir)/include > > might help. More correctly, the directory relative to $libdir is found by: $ ghc-pkg --show-package rts --field include_dirs $libdir/include Cheers, Simon

1 0

RE: location of HsFFI.h?
by Simon Marlow 30 Oct '02

30 Oct '02

> I was wondering whether there was any standard way to find HsFFI.h? I > can hardcode it into my makefiles for my own projects, but when i > distribute code, I end up having to add -I lines for every possible > location of it, usually multiplied by every compiler version > it supports > since that is often also in the path name. (and no, hmake is > not really > an option. pure make is my tool). perhaps some option to the haskell > compiler which spits out the appropriate flags to pass to the C > compiler. If you're using GHC, the trick is to use GHC to compile your C code too because it adds the appropriate -I flag to the gcc command line. If this isn't possible, then you can extract the information from the output of 'ghc -v'. The relevant directory is in the include_dirs field of the rts package. Cheers, Simon

3 2

location of HsFFI.h?
by John Meacham 30 Oct '02

30 Oct '02

I was wondering whether there was any standard way to find HsFFI.h? I can hardcode it into my makefiles for my own projects, but when i distribute code, I end up having to add -I lines for every possible location of it, usually multiplied by every compiler version it supports since that is often also in the path name. (and no, hmake is not really an option. pure make is my tool). perhaps some option to the haskell compiler which spits out the appropriate flags to pass to the C compiler. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

1 0

Re: Finalizers: conclusion?
by Marcin 'Qrczak' Kowalczyk 23 Oct '02

23 Oct '02

22 Oct 2002 01:32:55 +0100, Alastair Reid <alastair(a)reid-consulting-uk.ltd.uk> pisze: > -- keepAlive x y ensures that the finalizer for y is not run > -- until after the finalizer for x has run to completion. What if I do keepAlive p1 p2 >> keepAlive p2 p1? They will never be collected? -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

3 2

RE: The Death of Finalizers
by Simon Peyton-Jones 23 Oct '02

23 Oct '02

| In the meantime, I'm glad we have got a new function | atomicModifyIORef | which I for one will use, when it gets into GHC's regular release. Just before this gets out of the door... any chance of calling it modifyIORef and documenting that it's atomic? Sometimes names can get too long! Not a big deal though. Simon

4 4

RE: The Death of Finalizers
by Simon Marlow 22 Oct '02

22 Oct '02

> Do we still have atomicModifyIORef? > > I don't know that there's that much point now that Haskell finalizers > are gone. I don't have a strong objection (esp. since it seems every > implementation now has it) but it doesn't seem so necessary now. It ought to be significantly faster than using MVars if you can get away with it. I haven't measured it though. Cheers, Simon

2 1

RE: The Death of Finalizers
by Simon Marlow 22 Oct '02

22 Oct '02

> > It has a different type: > > > > atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b > > modifyIORef :: IORef a -> (a -> a) -> IO () > > It would break backwards compatability, but > > modifyIORef_ :: IORef a -> (a -> IO a) -> IO () > modifyIORef :: IORef a -> (a -> IO (a, b)) -> IO b > > (both specified atomic) would be consistent with the MVar names. Did you really mean those types, and not the types I quoted? That implies unsafeInterleaveIO if they have to be atomic. Cheers, Simon

2 1