[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: when GC is permitted
> From: Jim Blandy <jimb@xxxxxxxxxx>
> Tom Lord <lord@xxxxxxx> writes:
> > > Also, when running in a system with a precise collector and
> > > interrupt-anytime threads, Pika-style would require the elided
> > > mn__[begin|end]_incoherent() critical section calls?
> > No.
> > There is an independent and wholly unrelated reason to want those for
> > different examples, but they are not required for any of what we are
> > discussing.
> Under such a GC, would Pika-style scm_car and scm_cdr require critical
> sections to be marked internally?
To my mind, the specific mention of CAR and CDR is a red herring.
You could more clearly ask the more general question:
With a precise collector and interrupt-anytime (or concurrent)
threads, would there need to be GC-exclusion around all reads
from and writes to Scheme locations, as well as any cases
where a reference to a Scheme value may exist outside of any
Absent stronger guarantees about the C store than are provided by
the C standard itself, of course the answer is yes.
What you are really suggesting with your question is an issue about
some code which is semantically equivalent to the Scheme fragment:
(set! x (cdr y))
(set! x (car x))
In translating that into C code, and assuming that we pay a penalty
for GC exclusion, might we not get better code for:
(set! x (cdr y))
(set! x (car x)))
We certainly might. And that is a sound argument for making CADR a
_native_ function rather than one that would have to be implemented in
a portable FFI.
It is also a sound argument for portable FFI _extensions_ (i.e., not
essential in the first SRFI) that would allow C code like:
scm_clusterable_cdr (&result, instance, pair);
scm_clusterable_car (&result, instance, &result);
but the right to write such portable-FFI-using code is a privelege for
grownups who are stretching a good FFI to its limits -- not an
objection to using Pika-style conventions as the baseline.
(If you are looking at the CAR and CDR implementations in the Pika
code base -- note that they are not currently thread-safe. That's
why they're segregated into the `reps' ("representations") directory.)