Marc Feeley feeley@IRO.UMontreal.CA wrote/schrieb 200501200142.j0K1gL4f008223@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