On Wed, Apr 27, 2005 at 12:33:30PM -0600, Luke Palmer wrote:Dan Sugalski writes: > Also, with all this stuff, people are going to find timely destruction > is less useful than they might want, what with threads and > continuations, which'll screw *everything* up, as they are wont to do. > I know I've been making heavy use of continuations myself, and this is > for a compiler for a language that doesn't even have subroutines in > it. Continuations screw everything up, which is always fun, for > unusual values of 'fun'.
When I programmed in C++ with proper use of the STL and other such abstractions, almost the only time I needed destructors were for block-exit actions. Perl 6 has block-exit hooks, so you don't need to use destructors to fudge those anymore. And there's a lot less explicit memory management in languages with GC (that's the point), so destructors become even less useful.
I agree with Dan completely here. People make such a big fuss over timely destruction when they don't realize that they don't really need it. (But they want it). I think, more importantly, they don't understand what they're getting in return for giving it up.
Could you point out what i get?
I use TD is to handle resources: filehandles, database handles, gui windows and all that.
Sure, most people do. Heck, I do. And... I don't need timely destruction for them. Not in the "at scope exit this will be cleaned up" sense, at least.
"Timely" may be getting in the way here. Timely is as soon as possible but with very few exceptions it isn't necessary. (There are a couple of perl idioms that really demand it at the block level, but that's about it) A number of languages use it as an alternative to providing block exit actions, though those aren't really a great place for forcing finalizers, since you can't be sure that a thing is actually in a state to be finalized.
You've really got three classes of things that the GC system needs to know about. There are the things that need cleaning eventually (basically the no-finalizer objects), things that need cleaning up reasonably quickly (most things with finalizers, including most file and DB handles) where reasonably quickly's in the 100-200ms range, and things that need cleaning as soon as they die.
We don't provide any good support for instant destruction. People are just going to have to live with that, but honestly I don't think anyone's going to notice. (Though compilers can force a call to a PMC's finalizer if they want) For block-level cleanup there's conditional garbage collection and tagging PMCs as needing GC attention, which provides the support that most everyone needs. How expensive a sweep is depends entirely on how many PMCs you have, but the tracing part of the collector's darned fast, especially if you're using the aggregate PMCs that we provide, since they're special-cased in the collector.
Refcounting does this with a little overhead, but in a fast and deterministic O(1) way.
Deterministic, yes. Fast, no. Refcounting, in general, is about twice as expensive over the life of a program as other GC schemes.
And how do you want to implement glib objects with parrot? They are refcounted.
They'll be wrapped, so it's no big deal. When the PMC wrapping them dies, its finalizer decrements the refcount of the wrapped glib thing and leaves it to die on its own.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
