[e-lang] Leak avoidance for register-and-forget reactors
kpreid at mac.com
Sun Mar 25 23:20:02 CDT 2007
A while ago I proposed the addition of "weak when-more-resolved
reactors" in order to fix a memory leak where a promise which gets
resolved to a promise which gets resolved to a promise which ...
would accumulate resolved promises which never get shortened.
It now occurs to me that this could be handled with less specialized
magic by, instead of introducing a separate internal weak-when-more-
resolved protocol, using regular __whenMoreResolved but auditing/
stamping the reactor as a 'weak reactor', which can be amplified into
a weak reference to the object whose garbage collection implies the
reactor being useless. (This approval would be available to objects
transferred between communicating vats, as the sender can already
observe GC behavior.)
This generalization is particularly of interest because of a problem
I noticed with reactor protocols in general:
Consider a promise which doesn't resolve soon (or ever), or an
EverReporter which never, or infrequently, updates.
Both of these can have reactors registered (__whenMoreResolved,
whenUpdated) but will not (yet) trigger them. Furthermore, there is
no protocol for removing these reactors. Therefore, under certain
circumstances there will be an unbounded accumulation of reactors.
This occurred to me today when I was working on a GUI project. It is
natural to register reactors to update on-screen information; also
for such displays of information to be closed (and reopened), or
scrolled offscreen (and back on screen) in a list. In the worst
cases, there could be a continuing accumulation of reactors on a
single data source from what the user thinks of as a single displayed
So, what can we do about this?
One way is the weak reactors I propose above. It should be possible
to implement them in EverReporters as well as promises, though it
might require the reactor list to be opaque magic (only operations
being append/1 sendToAll/2).
I think it may be possible to allow safe definition of audited weak-
reactors (or have a sufficiently powerful library of builtin ones)
which would allow programs without weak-reference authority to avoid
creating this class of leaks.
Another way would be a protocol to cancel a reactor (e.g. reporter <-
whenUpdated(...) <- cancel()). I think this is equivalent in the case
where the registerer can make weak references and finalization, as
they can arrange to cancel the reactor when the target is GCed. This
is also sufficient when the registerer knows explicitly that there is
no longer interest. I don't see how it can be applied to
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang