[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Exceptions (was Re: Custom extensions to Lua)
- From: David Given <dg@...>
- Date: Fri, 12 Aug 2005 15:42:42 +0100
On Friday 12 August 2005 15:15, Lisa Parratt wrote:
[...]
> Tell me if this solution has any holes - I presume it must because it
> seems straightforward and simple - within a finaliser, make it illegal
> for the object undergoing finalisation to be on the right hand side of
> an assignment operation.
Hmm. It has possiblities. Thinking off the top of my head, some questions that
come to mind are: What about function calls? Would doing this still allow you
to pass the finalised object in as a parameter? What about constructing a
table containing the object and then saving the table?
I quite like the idea of enforcing a subset of the language for finalisers,
though.
> Care may be required to ensure that
> finalisers are called respecting hierarchy and that members for tables
> aren't marked for finalisation until the finaliser has completed, however.
Yeah, that's one reason for Java's baroque reachability state system.
An idea I'd been vaguely playing around with: if the gc notices that an object
is unreachable and has a finaliser set, instead of collecting it it adds it
to a specially-named table and takes no further action. Objects without
finalisers are collected as usual.
You then have some Lua code under application control that checks to see if
there's anything in this table, calls the finalise method if it so wishes,
and if the object genuinely needs to be destroyed, removes the finaliser and
drops the reference. It'll then be garbage collected again, but this time
properly destroyed.
This means that you don't need any wacky reachability semantics because
finalisable objects are normally live; plus, your code flow is much more
predictable because the application has complete control over when finalisers
are executed; but it *does* mean that objects may have their finalisers
called multiple times. The garbage collected also has to be more complex,
because when you resurrect an object to put into the table, you need to make
sure that none of its members have been collected.
[...]
> Sorry for rambling, and sorry for jumping in :)
Rambling? You call that rambling? Why, when I were a lad, we used to get up at
four in the morning and ramble for twenty-four hours before breakfast! Uphill
both ways, and in the snow, too...
--
+- David Given --McQ-+ "Why should we put ourselves out of our way to
| dg@cowlark.com | serve posterity? For what has posterity ever done
| (dg@tao-group.com) | for us?" --- Sir Boyle Roche
+- www.cowlark.com --+