Proposed change to ForeignPtr

[Alastair Reid]

> I think this is all a rather murky area.  Consider two systems,
> let's call them Haskell and Foogle, which both operate heaps and do
> their own storage allocation, but also communicate over similar
> FFIs.

This is indeed a murky area.

Especially tricky when you have two GC's (even if one is nothing more
than reference counting) is the issue of cycles that span the two
systems: neither side is willing to release its pointer into the other
world until the other side releases its pointer.  (See section 5.2 of
http://www.reid-consulting-uk.ltd.uk/alastair/publications/FP94.ps.gz
for more on the problem and a sketch of a fix.)

> We might very reasonably have situations where fairly complex
> inter-language pointers exist, so for example Haskell holds a
> ForeignPtr to something in the Foogle heap; the pointed-to Foogle
> object in turn references a Haskell object (presumably provided via
> StablePtr).  Now suppose Haskell wants to drop the ForeignPtr.  Then
> the logical thing for the finalizer to do is to tell Foogle that
> Haskell is no longer interested in the Foogle object.  This then
> gives Foogle the chance on its own garbage collection to in turn
> drop the Haskell StablePtr.  In turn this means somehow running
> StablePtr.freeStablePtr.  However this scheme I don't know if that's
> legal, because the Haskell finalizer you need to run "freeStablePtr"
> is indirectly provoked by the initial Haskell finalizer.

We should provide a C function hs_freeStablePtr and explicitly
say that it is safe to call this from inside a finalizer.

> Of course you would need at least reference counters (if you can
> guarantee there are no cycles containing both languages) or
> something more powerful otherwise, but reference counters at least
> can be provided. 

At least half the times I've used ForeignPtrs (aka ForeignObjs aka
MallocPtrs), I've had to implement my own reference counting so, yes,
it does seem like it'd be good to include reference counting in the
implementation somehow.  

I don't remember ever finding a good way to do it though.  The design
seems obvious enough but it seems there's always some odd little
wrinkle like the object already having its own reference counting
implementation or the other world wanting to talk about foo_t* (i.e.,
the type the external library provides) instead of hs_stablePtr_t.  In
particular, if I put a wrapper around an object so that I can attach a
reference counter, you somehow always find yourself faced with the
problem that a C library hands you a pointer to an unwrapped object
and you have to try to track down the reference counter for it.

Any ideas welcome.

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