On 2009-07-30, at 04:53, Abdulaziz Ghuloum wrote:
I've added post-gc-hooks parameter to revision 1833. Basically, it's
a list of thunks that are invoked after garbage collection. If the
hooks themselves cause GC, then they are run again, iteratively, until
they run without triggering GC (and thus have nothing more to do).
While running the hooks, the post-gc-hooks is parameterized to be '()
so as to avoid recursive calls to the hooks. So, the loop terminates
as long as one run of all the hooks does not GC. E.g.,
(parameterize ([post-gc-hooks (list (collect))])
(collect))
would run forever.
That's perfect!
A policy that prohibited calling the GC, calling the handler
recursively, or mutating GC handling in other ways (replacing the
handler,
for example), from inside the handler would be fine with me.
I think the design above meets your needs then.
This makes me VERY happy.
Just remember that there are no guarantees on when the GC discovers
that
objects are dead. Consequently, these handlers should remain
installed
until they're guaranteed to be no longer needed. I don't know the
best
way to make a handler uninstall itself cleanly. Maybe it's not too
important, since I don't think you'd have more than a few such hooks
at
any given time. But if you have any ideas, do let me know.
Totally agreed. In fact, I never thought of making post-gc-hooks a
parameter
(not that I object to doing so) because I can't really imagine any
design where
one would want to make a handler go away. (If I knew all of the
objects one
of these thunks manages have gone away, well, maybe yes. But if one
knows that,
why rely on the GC at all?) The two use cases I can think of are (a)
that a
hook gets added near the beginning of execution, and (b) some library is
loaded dynamically, and installs its hook as it's being initialized. In
neither case can I imagine uninstalling a hook.
I know that a lot of programmers don't really understand finalizers in
languages
such as C#, expecting the execution of a finalizer to be predictable.
I think
the specification at the beginning of your email and the warning in
the above
paragraph are essential parts of the documentation for this feature,
to avoid
bug reports of the `I called collect but it didn't run my finalizer'
variety.
Once again, thanks, this is exactly what I was hoping for.
-- v
