Re: [MIT-Scheme-devel] sqlite3

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Sat, 18 May 2013 23:31:23 +0000
> 
> [...]
> Sqlite3 is not a generic event dispatch loop.  The purpose of its
> progress handler is to let you run an event dispatch loop [...]

Actually the documentation says "to keep a GUI updated".  The problem
with expanding that into "run an event dispatch loop" is that
interleaving two mainloops is like serving two masters: one is always
blocking when the other wants to run.

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(?).

I can add a with-other-threads-allowed procedure that the "progress"
callback can use to allow thread switching, much as you did in
microcode-callback.

> 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.

The callback implementation you attached is mostly about replacing a
vector of registered callbacks, O(1), with a red-black tree, O(log n).
That and your pre-occupation with the enabled interrupts is... weird.