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

Re: when GC is permitted

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 are here. Eventually, the entire history will be moved there, including any new messages.

    > 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
        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:

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