On Sun, 18 Jan 2004, Tom Lord wrote:

>    > From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
>
>    > Ray> It's not immediately obvious to me how to implement some of the
>    > Ray> functionality that's not allowed to GC without allocating call
>    > Ray> frames - particularly since strings are represented internally
>    > Ray> as a tree structure.  I'll look more closely at it tomorrow and
>    > Ray> cite specific cases.
>
>    > As to the strings & characters issue---we all agree that it
>    > needs to be addressed.  But apart from that?

Okay, more specifically:

String representation as a tree means I would need to be able
to allocate call frames (and potentially GC) for string-ref and
string-set (SCHEME_STRING_REF and SCHEME_STRING_SET as they
appear from the C side). That's separate from the character
representation issue.

I can get around most of the other stuff because the call depth
is possible to know in advance, but with the string representation,
the number of frames I'd need to allocate is the length of the
longest path from root to leaf, which isn't known in advance.

> I think "may GC" applies to all entry points.

I tend to agree, but this means no live C pointers directly at
storage occupied by scheme data.

> Even something banal like "extract_double" may wind up having to
> reduce a number by running Scheme code (as in a bignum rational with
> bignums implemented in Scheme (or just on the Scheme heap) or a
> continued fraction numeric extension written in Scheme).

Depends, probably, on rational representation issues.  It's
possible, for me at least, to bitmask & shift the first three
words of the numerator and the first three words of the denominator
to derive C doubles by bitfiddling, then do an FPU division and
return a C double without running scheme code.  I'd normally
run scheme code as accessors, since rationals differ by only a
typetag from cons pairs, but can't without risking GC. The problem
is surmountable since I know in advance the exact depth of
the call stack I'm going to need (one frame, first for car and
then for cdr). I can preallocate it before starting and so avoid
GC during the call.

But these methods heavily depend on the rational representation,
so in general, you're right.

>I think we've cooked down the implications of some FFI design space
>parameters to this:
>
>
>   Parameter			Restricting		Resulting
>				Choice			Restriction
>   ----------------------------------------------------------------
>
>   A. GC only at certain	Yes		Aynchronous threads may
>      C sequence points?			not cause GC;  signal
>                                        	handlers may not cause
>                                                GC
>
>   B. Scheme values		Yes		Requires A
>      repesented as
>      C rvalues?
>
>   C. Barrierless reads		Yes		Certain incremental GC
>      and writes to Scheme			techniques prohibited;
>      locations?				Requires A and B

I would say that this is an excellent summary.  Barrierless reads (C)
are probably the biggest problem here as far as I'm concerned.  I
could live with sequence-point GC (A).

>Supposing that your choice is (A+B) or (A+B+C), then there's a new
>parameter which is what you're asking Ray about:
>
>
>   D. Some FFI functions may	Yes		Scheme types not extensible
>      not cause GC                              in Scheme;
>                                                Some scheme types or procedures
>                                                not implementable in terms
>                                                of others;
>                                                (Implies A, of course)

I think you've hit the nail on the head here.  Using scheme
code to handle the representations is out if you can't
allocate scheme call frames in order to manipulate those
representations from C.  It becomes a sort of callback
even though not an explicit one.

				Bear