Date: Sat, 3 Jan 2004 17:16:58 -0800 (PST)
   From: Tom Lord <xxxxxx@emf.net>

       > From: Richard Kelsey <xxxxxx@s48.org>

       > 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