Felix Winkelmann <xxxxxx@proxima-mt.de> writes:
> > What he wrote seems clear enough.  If SRFI-50 provided a begin/end
> > pair of functions that indicated that the calling thread was holding
> > no references to heap objects, then collection wouldn't need to wait
> > for threads in that state.  One could call the 'begin' function when
> > beginning use of SRFI-50 functions, and the 'end' function when
> > leaving the module.
> >
>
> I don't understand this. If the C code does not hold direct references
> to the data (i.e. if you add an extra indirection), and if you access
> the data only over a designated interface, GC can certainly run
> whenever it wants, even during the execution of the C code. That's
> the whole point of the abstraction exercise.

I'm sorry.  I shouldn't be trying to write so late at night.

In code using this SRFI's interface, there are two classes of Scheme
values:

- Values that reside in GCPRO'd variables.

- Values that reside anywhere else: in other variables,
  compiler-generated temporaries, and so on.

Values in the first class the GC can update when it relocates objects;
those in the second class it cannot, because it can't find them.
Values in the second class are unavoidable if you're actually
operating on the values, since you can't control the code the compiler
generates.

By using the 'begin / end' pair of functions, you'd promise the
SRFI-50 implementation that, outside such pairs, no values of the
second class exist, and it is free to collect at any time.  When any
thread is within such a pair, there exist object references the
collector can't find or update, so collection has to wait until the
thread reaches a "may gc" function.

Is that better?  Or worse?  :)