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.
Date: Sun, 4 Jan 2004 14:09:20 -0800 (PST) From: Tom Lord <lord@xxxxxxx> 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.) The proposed SRFI works fine with threads, as long as those threads do not require interrupting the C code at arbitrary points. 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 You haven't convinced me on these points. You have given examples of misuses of the FFI, in which values are left in unprotected locations during a call to a possibly-GCing procedure. Yes, then you get problems, and yes, that is a drawback to the proposed FFI. But it doesn't mean that the proposed FFI doesn't work with threads, read/write barriers, or transient root set members. It means that it takes some care to use properly. 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. Yes, and more overhead for accessing Scheme values from C. It's a tradeoff. We made it one way and you would make it another. -Richard