Weak pointers and STM

[Simon Marlow]

Lennart Augustsson wrote:
> Finalizers without guarantees, like what ghc implements, are totally 
> useless. Since there is no guarantee that the finalizer will ever run 
> attaching one is a no-op. It has bitten me several times. I wish ghc 
> implemented finalizers according to the ffi spec.

We do plan to do that (I'm sure you're aware of bug #1364), however I'm 
sure you're also aware that GHC's finalizers are more general than the FFI 
spec requires in that finalizers can be Haskell computations, and it is 
this that leads to the lack of guarantees.  Implementing the FFI-style 
finalizers requires us to treat C finalizers as a special case, rather than 
implementing them as foreign calls from Haskell finalizers, which is a bit 
of a pain.

I disagree that finalizers are completely useless.  They're just not useful 
for some of the things you might like them to be useful for, like 
guaranteed resource reclamation.

>    -- Lennart (iPhone)

Cheers,
	Simon (MS natural keyboard and 28" LCD screen)

> On Dec 7, 2008, at 13:12, "Claus Reinke" <claus.reinke at talk21.com> wrote:
> 
>>> Adding finalizers to arbitrary objects was useful for the memo table 
>>> application we had in mind when weak pointers were introduced, but 
>>> for all the other applications I've come across since then, we really 
>>> want to add finalizers to objects whose lifetimes are under 
>>> programmer control.  Notice how ForeignPtrs attach the finalizer 
>>> carefully to the MutVar# inside the ForeignPtr, not the ForeignPtr 
>>> itself.
>>
>> One application that was effectively killed by GHC's approach to
>> finalizers was GHood (I lost interest when it became apparent that
>> GHC was moving away from giving any kinds of guarantees about
>> finalizers). The idea was that, just as unsafePerformIO gives us a
>> way to instrument the evaluator, so finalizers could have given us a 
>> way to instrument garbage collection. Then GHood could not only
>> have shown when which parts of which structure are first observed
>> (how and when structures get unfolded) but also (roughly) when which 
>> parts of which structure become unreachable (how and when
>> structures disappear again). That would have made a very nice tool.
>>
>> But it would have needed finalizers on arbitrary objects that are
>> actually guaranteed to be run, preferably promptly, but not early. 
>> Given the application, I would have considered wrapping/annotating 
>> those objects in some transparent way, not visible to the original 
>> program, but forcing the memory manager to keep track of that object 
>> even if that means worse code. Only that there are no guarantees 
>> whatsoever on these finalizers anymore (there were some back then, but 
>> it emerged that they weren't backed up by the implementation).
>> Which also hurts other, table-like, applications: I have an 
>> application where I need to keep track of synchronous communication 
>> channels, basically: advance each live channel at every step. Now, I 
>> would like to attach finalizers to the channels, so that when there 
>> are no more threads having references to a channel, the channel gets 
>> removed
>> from the tracking table. But without finalizer guarantees, there is no
>> guarantee that the table will not simply keep accumulating more and
>> more of those dynamically created channels..
>>
>> I, for one, would like to have good support for "adding finalizers to 
>> arbitrary objects with useful run guarantees". Actually, it is a bit hard
>> to understand what finalizers without any guarantees (System.Mem.Weak)
>> are supposed to achieve?
>>
>> Claus
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users