On Jul 31, 2009, at 12:26 AM, Vincent Manis wrote:
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?)
Here's one scenario:
* You have a counter for how many resources are created, initially
set to zero.
* When you create a resource and register it with a guardian, you
increment the counter. If it was zero, you install the gc hook
as well.
* Every time the gc hook frees a resource, it decrements the counter
and if the counter drops to 0, the hook uninstalls itself since
it's no longer needed and will be reinstalled if new resources
are ever created again.
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.
As you say, typically a library will install its hooks when it's
initialized. But libraries can also be uninstalled in Ikarus,
leading to hooks that stick around indefinitely, which is not good.
Maybe a gc hook should return a value indicating whether it should
stay or be uninstalled. That way, we'd only need a way to *add*
hooks (thus, the interface won't be in the form of a parameter),
and the hooks themselves would be responsible for uninstalling
themselves, if ever.
How does that sound?
Aziz,,,
