Date: Sun, 4 Jan 2004 17:16:40 -0800 (PST)
   From: Tom Lord <xxxxxx@emf.net>

   Reading or writing to or from root values (or any other Scheme
   location) in an incremental, copying collector requires a read or
   write barrier in order to preserve the tri-color invarient -- but the
   naked C assignment `x = y' affords no such barrier (hence, permits the
   invariant to be violated).

With an incremental collector reading or writing to or from
heap objects may require a read or write barrier.  Reading or
writing root values does not (and cannot - how do you get a
read or write barrier on a machine register?).

   In order to preserve the invariant in the face of C's assignment
   operator, at least all GC_PROTECT_GLOBAL locations and all GC_PROTECT
   automatic variables must be, whenever such an assignment is possible,
   the same color.   Unless the draft is modified to prohibit assignments
   of the form `x = *z' where `z' is a `scheme_value *' that may point to
   a GCPROtected automatic in some caller's frame -- then _all_
   GCPROtected locations must be of the same GC color whenever a foreign
   function is executing code between GC points.

No.  All that is required is that the incremental GC scan the
entire root set in a single increment before deciding that it
has reached the end of a copy cycle.  This is standard practice
for incremental GCs.

SCHEME_CAR() and SCHEME_SET_CAR() and so forth need to preserve
any read or write barriers, of course.

   (You also talk about threads and interruption points related to them
   but, of course, that doesn't address truly concurrent threads.)

I am not sure what 'truly concurrent' means (parallel execution?).
But yes, we chose efficient C execution over allowing the C code
to be interrupted at arbitrary points.
                                            -Richard Kelsey