> From: Jim Blandy <xxxxxx@redhat.com>

    > Tom Lord <xxxxxx@emf.net> 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
        Scheme location?

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:

	(with-gc-excluded
	  (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_GC_EXCLUDED_BLOCK_DECLS;

          [....]

          SCM_GC_EXCLUDED_BLOCK_BEGIN;

          [....]

	  scm_clusterable_cdr (&result, instance, pair);
	  scm_clusterable_car (&result, instance, &result);

          [....]

          SCM_GC_EXCLUDED_BLOCK_END;
        }

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.)

-t