[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

When you say that SCHEME_GC_PROTECT "registers the <n> variables
(lvalues) with the garbage collector" you mean, I believe, to say that
it adds them to its root set?  This would protect the variables, and
anything reachable from them, from GC, regardless of whether they are
reachable from any other scheme variable.

When you say that SCHEME_GC_UNPROTECT "removes the block's protected
values from the garbage collector's list" you mean, I believe, to say
that it removes them from its root set?  They would still be protected
from GC if they are still reachable from anything in the remaining
root set.

If this is what you mean, then I don't think there is a problem with
it except that maybe the wording should be clearer abut the visible
consequences.  If something else is what you mean, then more words
should be used to explain exactly what the visible consequences of
making these calls will be.

Is there a rationale for the number 12 in the definition of
SCHEME_DECLARE_GC_PROTECT?  It seems an odd choice when it's just as
easy to protect a single freshly-allocated scheme vector of arbitrary