On 2009-07-28, at 15:27, Abdulaziz Ghuloum wrote:
On the same topic, is there any plan to have something like Chez's
collect-request-handler, or some similar mechanism? (Or maybe I
missed
an existing mechanism when peering through source code?)
There isn't one in Ikarus currently. I need to think about it more
before committing to the idea. (these handlers would run concurrently
with the program, and may fire at any point, and they themselves may
cause further recursive GC/handler calls, which would be fun to debug
to say the least)
The two practical applications for this that I can imagine are running
finalizers and doing user-defined logging collections. So if the handler
is limited in what it can do, that's fine with me.
I prefer the strategy where the handler runs after the collector is
finished,
making for an `after-gc-is-complete' hook. If the handler wants to call
the GC, that should work OK, and wouldn't be a true recursive GC call;
I feel totally neutral about the handler invoking itself recursively,
and probably would at least want to discourage it, even if it were
easy to
implement. 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.
Such a handler can still exhibit all the nasty characteristics of any
asynchronously-called callback, but some proper structuring of the
handler
should render the asynchrony manageable. I do NOT want to ask you to
implement things that would be `fun to debug', at least not unless you
want to! :-).
In my graduate days, I worked as a peon on a never-completed ALGOL 68
compiler.
Every design decision was premised on the theory that there could be
`fifty pages of code between this pair of parentheses', even though
the average
use case had half a dozen tokens. This left me with a cordial distaste
for
design philosophies based on allowing everything that is humanly
conceivable,
useful or not.
I guess it's pretty obvious that I'd like to be able to finalize and
reap inaccessible values registered with a guardian automatically
on GC.
What kind of resource are you protecting? Is the usual strategy
(e.g.,
finalizing dead resources when new resources are created) not
sufficient
in your case? This is what Ikarus uses for file handlers.
In this particular example, I have resources (server connections,
actually)
that are all created early in execution, and then it's likely that no
more
will be created. So the GC represents an opportunity to catch these
defunct
values and close them properly.
One of the things I like most about guardians is the reap-on-new-
resource-creation
idiom. So my notions re the GC are a belt-and-suspenders approach;
relatively
few finalizers should survive to be invoked by a GC handler in this
model.
Thanks! -- v
