Re[2]: Weak pointers and STM

Hello Simon, Monday, December 8, 2008, 2:53:01 PM, you wrote: just a detached look: may be provide Haskell finalizers with the same (lack of) warranties?

The way to use finalizers is in conjunction with an exception handler that provides an absolute guarantee that the resource will be reclaimed on exit.

Note that Java doesn't guarantee to run finalizers on exit either:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#runFinalizers...)

Although in Java it's for different reasons.

We can give more guarantees to C finalizers because they're much simpler:

- a C finalizer can't synchronise with other Haskell code, including Haskell finalizers. - we don't have to worry about whether a C finalizer refers to other finalizable objects - we don't mind if a C finalizer blocks: that's the programmer's problem.

Cheers, Simon

Lennart Augustsson wrote:

...

From a theoretical perspective I'd say that they are completely useless, because there's no guarantee that the finalizer will ever run. You might as well throw them away as use them and there would be the same guarantees. From a practical perspective they are useful, because they probably run. So you can use them to reclaim most resources.

I realize that the situation is complicated in ghc, but it also means that to get finalizers with guarantees you have to implement them yourself rather than relying on the ghc runtime system, which can be quite tedious.

-- Lennart

On Mon, Dec 8, 2008 at 9:59 AM, Simon Marlow wrote:

...

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" 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com