At 10:24 PM +0100 1/2/03, Angel Faus wrote:
Yech, refcounting is one of the things we're trying to avoid. The cost and error-prone-ness is its big downfall.>The best partial solution to early finalization is compile-time tracing of possible references by the compiler which can explicitly generate the appropriate DESTROY calls.What about refcounting + real GC?
Anyway, to respond to the whole thread here, as I dig through my mail backlog:
1) We're not generally guaranteeing timely destruction
2) If something *wants* timely destruction, it can push a DOD run as a scope exit action. If something needing scope exit cleanup actually escapes its construction scope, odds are it'll live for some indeterminate time anyway, so that's fine
3) If #2 isn't sufficient, we can consider having a "needs timely cleanup" flag with corresponding interpreter counter, and on scope exit if the counter is non-zero a DOD run can be scheduled, with the interpreter handling the counter.
While I don't really like walking the system stack and probing the registers on DOD runs, the cost seems generally lower and less error-prone than explicit save/unsave actions that happen every time a PMC or buffer is allocated, and I'd like to start working in some sort of adaptive allocation/collection code so the DOD/GC doesn't fire off every time there's temporary resource starvation.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
