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: Sat, 3 Jan 2004 17:16:58 -0800 (PST) From: Tom Lord <lord@xxxxxxx> > From: Richard Kelsey <kelsey@xxxxxxx> > Within the context of this SRFI I don't care about asynchronous > execution (I do care about threads, but as long as C code is not > interrupted asychronously they don't matter). The GC protection > mechanism described in the SRFI is inadequate if GCs can occur > asynchronously. Even if variables 'a' and 'b' are protected, > there is no guarentee that a = b; will not temporarily store the > value of 'b' in some unprotected location such as a register. which I perhaps misinterpreted to mean that there is in effect a final decision by the authors not to change the calling conventions to either the JNI/minor-style or Pika-style conventions that jimb and I proposed. I don't know about final, but it certainly is the decision at this point. And it isn't because we don't care about the issues that you care about, just that we have different approaches to dealing with them. 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. The choice between Pika-style and the proposed SRFI comes down to whether thread switching (and thus GCs) is allowed at any point or only at discrete moments. My experience has been that latter makes for simpler and more reliable programs. And yes, the current FFI allows you to write code that delays thread switching indefinitely. It also allows you to write code that leaks storage or segfaults. If you are going to use a library you have to make sure that it meets your needs, regardless of whether or not it includes C code. If you use threads it will have to be thread safe. If you have realtime requirements, it has to meet those requirements. This SRFI cannot either require or restrict C code to be either thread safe or be non-blocking. Neither does it prevent anyone from writing thread safe or non-blocking C code. 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. -Richard Kelsey