At 10:24 PM +0100 1/2/03, Angel Faus wrote:
>> 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?
Yech, refcounting is one of the things we're trying to avoid. The
cost and error-prone-ness is its big downfall.
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.
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk