This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
On Sun, 18 Jan 2004, Tom Lord wrote: > > 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? 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