[gambit-list] Re: SQLite 2.4.7
feeley at IRO.UMontreal.CA
Wed Jan 19 20:42:21 EST 2005
> since I couldn't find an existing SQLite 2.* loadable module for
> Gambit 4.0, I tried to create one myself, using Gambit-C 4.0 beta 11:
> Please tell me about another implementations for the same purpose, if
> available. Otherwise please suggest improvements on my implementation,
> which may be poor and errornous, because I'm new to Scheme and Gambit.
Sounds interesting. Why did you choose SQLite rather than mysql?
Here are some comments on your code.
Callbacks are fine in a single threaded program. However, because of
the way continuations are handled (and Gambit uses continuations to
implement preemptive threads) it will not be possible to reliably have
more than one thread interacting with the database. Imagine the
situation where thread T1 has called sqlite_exec and the callback
function gets interrupted at the end of T1's quantum, transferring
control to T2 which also tries to call sqlite_exec and the callback
function gets interrupted at the end of T2's quantum. Up to this
point there isn't a problem. However when T1's callback resumes
execution and returns, the C stack will have to be unwound to return
back into sqlite_exec. This has the side effect of removing
from the C stack the call frame for T2's call to sqlite_exec (using
a longjmp). So when later T2's callback is resumed, it is not
possible for it to return back to C. Unfortunately there is only
one C stack! (there is a way to solve this, see one of my
Scheme workshop papers, but it hasn't been implemented because
of the high overhead)
A better approach is to use the sqlite_compile, sqlite_step,
and sqlite_finalize API which does not use callbacks.
More information about the Gambit-list