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#runFinalizersOnExit(boolean) > 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
