[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