Date: Sun, 4 Jan 2004 14:09:20 -0800 (PST)
   From: Tom Lord <xxxxxx@emf.net>

   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