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.
> From: bear <bear@xxxxxxxxx> > > 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. You mean such as a C `char *' pointing directly at, say, some string data? If so, no -- that's not what it (necessarily) means. That's a topic we haven't taken up much and is slightly tricky, imo. Options to consider are the ability for C code to dynamically declare GC-excluding regions (within which at most a subset of the FFI is available) and the ability to dynamically declare regions during which certain objects are "locked" (with, again, limits on what part of the FFI is available). In a portable FFI, the issue is especially nasty because you can (_probably_) have at most the mere possibility of sharing and only read-only access -- within an implementation, you have to solve the same issues but with sharing guarantees and mutability. (I say "_probably_" because I can imagine wackiness like an FFI that permits sharing to be simulated in implementations that can't permit it direcctly but that seems pretty excessive to me.) > >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). I think that, in general, A alone is the least controversial. But another way to view the design space is that if you want an FFI that doesn't imply "C", then the seemingly natural choices for that FFI also don't imply "A" and aren't consistent with "B". In other words -- once you say no to "C", there's no good reason not to say no to "A" and "B" too. The strucutre sharing issues _might_ give a reason to say yes to "A" without implying "B" or "C" -- but they shouldn't be exposed in a portable FFI. > >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. Thanks. It's helpful to me to have second opinions like that -- I do sometimes worry that I've missed something somewhere. -t