ForeignPtr naming

[Alastair Reid]

> This is all fine, except that implementing finalizer ordering slows
> down ForeignPtrs quite a bit, in particular mallocForeignPtr takes a
> 20% hit just allocating the IORef needed to store the list of
> finalizers.  Ideas for a better implementation are welcome.

Having obviously optimized the hell out of mallocForeignPtr, it sounds
like it's time to optimize the hell out of IORef. :-)

Or, on the assumption that the slowdown comes from splitting what was
a single object into 2 or even three separate objects, do what it
takes to turn it back into a single object - i.e., put a mutable
field directly in the MFP object.

Best of all, do as CAML has done and add the machinery (and semantics
changes) necessary so that whenever you have a tuple with a mutable
field in it, GHC will implement it without adding an indirection
through a separate IORef object.  Highly worthwhile and might possibly
help with your MFP problem :-)

> Anyway, this message is really about what names we should use for
> the old Haskell-finalizer versions of newForeignPtr and
> addForeignPtrFinalizer (and as such it doesn't have any bearing on
> the FFI spec 1.0).

I'm rather taken by 'oldNewForeignPtr'.

> I'm assuming that we want to keep these functions in some form in
> GHC - where to put them is one issue; Foreign.ForeignPtr is a
> possibility (but not ForeignPtr), or GHC.ForeignPtr.

I'd put them in GHC.ForeignPtr and make no other change in their name.

Easy for people to transition, easy for people to see non-portable
code, probably little risk of collision with the ffi-mandated FunPtr
versions.

--
Alastair Reid                 alastair at reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/