[gambit-list] more than one thread, no return to C (was: SQLite 2.4.7)

Thomas Hafner hafner at sdf-eu.org
Wed Jan 26 20:22:17 EST 2005


Marc Feeley <feeley at IRO.UMontreal.CA> wrote/schrieb <200501200142.j0K1gL4f008223 at baro.iro.umontreal.ca>:

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

Given the general case, that a Scheme procedure calls a C function
which in turn calls another Scheme procedure: does it matter whether
the inner (latter) Scheme procedure is a callback procedure (i.e.
given by the caller of the outer Scheme procedure) or not? I don't
think so. Is this then the general rule for avoiding the problem:
don't nest Scheme procedure calls indirectly via C?

  Thomas



More information about the Gambit-list mailing list