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: Richard Kelsey <kelsey@xxxxxxx> > The JNI style of FFI, where the C code has indirect references > and never the Scheme values themselves, has lots of advantages. > But it does add overhead. I would prefer an FFI that allowed a > choice of direct or indirect values on a per-function basis. > Which is preferable depends a lot on what the C code is doing. > Such an FFI would be even larger than the current one, which is > already big. Pika-style conventions come very close to letting the compiler decide when direct vs. indirect references are needed. So close that I think you can just leave it at that and not suffer. > The interaction between Scheme threads and C code is complex. It > deserves a separate SRFI because of the complexity, because of the > dependencies on the details of both the thread and C FFI systems, > and because not every FFI user is going to care about it. If this issue were _only_ about threads, that might be a reasonable argument. (It also might not: one could argue that you shouldn't finalize a SRFI which is demonstrably unsuitable for threaded situations.) But the problems with the current FFI include issues with single-threaded, no-async-issue Scheme implementations including: ~ don't handle read/write barriers properly ~ don't handle transient root set members properly By stunning coincidence (or deep physical truth, take your pick), it turns out solving those issues _also_ make the FFI much more suitable for systems with threads (including truly concurrent threads) and async-execution. There's another way entirely to look at the calling convention issues: The draft FFI makes strong presumptions about the representations of Scheme values and the invarients that must be maintained wrt to the Scheme heap. It makes these presumptions by leaving it up to the compiler of FFI-using functions to manipulate scheme values directly, constrained only by the semantics of C. Pika-style conventions do not make those presumptions: there is a comprehensive abstraction barrier there between the Scheme value representations, the heap invariants, and the C code. The latter is far less restrictive on Scheme implementations. -t