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