Re: [MIT-Scheme-devel] sqlite3

[Taylor R Campbell]

   Date: Sat, 18 May 2013 22:23:25 -0700
   From: Matt Birkholz <address@hidden>

   If you are saying the library never has to block on any channels(?),
   then _progress_handler may do fine.  It may even be acceptable if
   it blocks Scheme just a little(?).

The sqlite3 progress mechanism is based on progress in executing a
query, not anything to do with I/O.  (Sqlite3 may block in I/O -- it
repeats system calls on EINTR -- but except on remote file systems or
screw cases like fifos, which are a bad idea for sqlite3 anyway, it
shouldn't block for longer than the local disk's latency.)

   > The callback implementation I attached preserves the set of interrupts
   > enabled from C to the Scheme callback,

   Why do you mention this in particular?  It seems odd.  The enabled
   interrupts at the point of a callback are always /gc-ok.  There is no
   point in saving them.  Interrupts have to be saved/disabled before the
   preceding callout, else you will have holes.

I mentioned it because you were worried about undesirable thread-
switching in callbacks.  If you disable thread timer interrupts on
entry to the microcode, then this state will be preserved on entry to
the Scheme callback, in order to avoid said thread-switching.  For
microcode primitives, it is not a priori the case that interrupts are
disabled on entry.


I will admit that I haven't looked very closely at your FFI's
implementation.  The magic happening in the macros is very hard to
follow (C-INCLUDE, for example, expands to nothing -- it seems that
you are abusing macros for side effects rather than expansion), and
using it without installing things in $PREFIX/lib/mit-scheme-$ARCH
doesn't seem to be supported.  It's also not clear to me why Scheme
needs to memorize so much information about the C platform's ABI (and
the grovelling mechanism will get in the way of any attempt at cross-
compilation), when you're already generating C code for the shims.