Email list hosting service & mailing list manager

(Previous discussion continued)
Re: no constants please Richard Kelsey (04 Jan 2004 18:09 UTC)
Re: no constants please felix (04 Jan 2004 19:28 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 20:06 UTC)
Re: no constants please Tom Lord (04 Jan 2004 21:39 UTC)
Re: no constants please Tom Lord (04 Jan 2004 22:09 UTC)
Re: no constants please Richard Kelsey (04 Jan 2004 22:58 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:16 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:45 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 11:40 UTC)
Re: no constants please Tom Lord (05 Jan 2004 16:51 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 17:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:50 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 18:48 UTC)
Re: no constants please Tom Lord (05 Jan 2004 22:26 UTC)
Re: no constants please Michael Sperber (06 Jan 2004 07:42 UTC)
I don't believe in "(may GC)" Tom Lord (05 Jan 2004 01:21 UTC)
Re: I don't believe in "(may GC)" Richard Kelsey (05 Jan 2004 12:06 UTC)
Re: I don't believe in "(may GC)" Shiro Kawai (05 Jan 2004 12:45 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 18:16 UTC)
Re: I don't believe in "(may GC)" Tom Lord (05 Jan 2004 17:00 UTC)
Re: I don't believe in "(may GC)" bear (05 Jan 2004 17:53 UTC)
Re: I don't believe in "(may GC)" tb@xxxxxx (06 Jan 2004 01:39 UTC)
Re: I don't believe in "(may GC)" Michael Sperber (06 Jan 2004 07:39 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:31 UTC)
Re: no constants please Tom Lord (05 Jan 2004 01:38 UTC)
Re: no constants please Richard Kelsey (05 Jan 2004 12:16 UTC)
Re: no constants please Tom Lord (05 Jan 2004 18:05 UTC)
Re: no constants please Michael Sperber (05 Jan 2004 19:03 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 01:37 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 02:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 02:55 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 02:31 UTC)
Re: no constants please Richard Kelsey (06 Jan 2004 03:09 UTC)
Re: no constants please tb@xxxxxx (06 Jan 2004 03:14 UTC)
Re: no constants please Tom Lord (06 Jan 2004 04:32 UTC)

Re: no constants please Richard Kelsey 04 Jan 2004 18:09 UTC

   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