[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Couple things...
> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> 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?
I think "may GC" applies to all entry points.
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).
Other examples of the problem are process migration and persistent
stores which are, I think, something that people are likely to take a
stab at more often these days. If anything, very simple
implementations are one of the more likely places for those kinds of
feature to show up.
(Why the "constants" should be an exception to "may GC" is something I
I think we've cooked down the implications of some FFI design space
parameters to this:
Parameter Restricting Resulting
A. GC only at certain Yes Aynchronous threads may
C sequence points? not cause GC; signal
handlers may not cause
B. Scheme values Yes Requires A
C. Barrierless reads Yes Certain incremental GC
and writes to Scheme techniques prohibited;
locations? Requires A and B
Note that (not A) implies (not (or B C)). Coherent choices here are:
1. no to all three
2. A (and B?) (A+B has no disadvantage compared to A?)
3. A, B, and C
each progressively more restrictive than the last.
(The chart doesn't talk about "human factors" restrictions like
tempting users to mistakenly write `cons (a, cons (b, nil))'.)
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
(Implies A, of course)
which strikes me as eerily Java-esque. Incrementally better in that
there is still a _little_ room to "subclass" (for example) the number
type or cons-pair type -- but only by a tiny increment since there
would still be a huge restriction on representations of (for example)
small, exact, integers or pairs. (So much for that big Oaklisp
In all cases, the "resulting restriction" becomes implicit in
FFI-using code. An implementation that promises users support for an
A+B+C+D FFI in one release can not also promise to add asynchronous
execution in an upward compatible way, can not plan to use certain
incremental GC techniques while remaining upward compatible with code
that uses the FFI, and can not promise to compatibly add extensibility
of the basic Scheme types.
Does it make sense to request implementation of those restriction
in other people's implementations?