Hi Marc,
FYI
The file gambit.el in the latest (4b12) distribution has a comment line near the start
;; (setq scheme-program-name "gsi -:t")
After pasting this line in my xemacs init.el the interaction window didn't work. Changing it to
;; (setq scheme-program-name "gsi -:d-")
as described in the doc fixed it.
Since others, like me, will be tempted to cut and paste from the gambit.el file comments to init.el it would be nice to fix the comment.
Regards,
OK.
Marc
Afficher les réponses par date
Hello,
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: http://hafner.sdf-eu.org/pool/sqlite-g0.1.shar.txt.
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.
Regards Thomas Hafner
Hello,
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: http://hafner.sdf-eu.org/pool/sqlite-g0.1.shar.txt.
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.
Marc
Marc Feeley feeley@IRO.UMontreal.CA wrote/schrieb 200501200142.j0K1gL4f008223@baro.iro.umontreal.ca:
Sounds interesting. Why did you choose SQLite rather than mysql?
I intend to use the DB on SDF-EU http://www.sdf-eu.org/, where I have a shell account as a supporting member (so called ``MetaARPA''). There is also a MySQL DB, but I had to pay more to use it. I can compile my own stuff there as far as I don't run of quota, but I'm not allowed to run server processes. So I guessed, that SQLite fits better to my needs than MySQL.
Another reason is, that SQLite lets me link with my stuff to a standalone program, that I can deliver to somebody else without forcing him to install/configure dependent stuff (``embedded DB'').
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. [... detailed explanation ...] A better approach is to use the sqlite_compile, sqlite_step, and sqlite_finalize API which does not use callbacks.
The API you're describing is not provided by SQLite version 2.4.7, but I remember I've seen it already somewhere. I guess it's part of a more recent version of SQLite.
Does somebody know an already existing Gambit adapter for that newer SQLite API?
The reasons why I'm still using the old version of SQLite are: - SDF-EU runs NetBSD 1.6.2, and last time I've checked the NetBSD source package tree, I havn't seen a newer version of SQLite there. - At home I've Debian 3.0, also missing a newer SQLite version -- of course: typically Debian stable :-)
It seems to me, that I can do one of the following alternatives: - Pay for MySQL access. - Keep all like it is, but let only one thread per program use the DB. - Try to build the newer SQLite version on NetBSD 1.6.2 and Debian 3.0 and write a Gambit adapter using the interfaces that you've proposed.
Thanks for the hints.
Regards Thomas Hafner
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
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?
Whether it is a callback or not is immaterial. The important thing is that you have a call from Scheme to C in which is nested a call from C to Scheme. In such a situation the "continuation" contains C frames. There is a risk that these C frames will be popped by an (unrelated) call to a continuation that contains another C frame (that was pushed on the C stack earlier). This might happen in a multithreaded program if more than one thread does these Scheme -> C -> Scheme calls and the scheduler interleaves the execution of the threads (because of preemption, I/O blocking the threads, etc). When there are only Scheme to C calls the issue does not arise.
Marc
Marc Feeley feeley@IRO.UMontreal.CA wrote/schrieb 200501270203.j0R23Xsd015151@baro.iro.umontreal.ca:
When there are only Scheme to C calls the issue does not arise.
Thanks.
BTW, I've changed the subject line in my last message to Subject: more than one thread, no return to C (was: SQLite 2.4.7) but the mailing list software just made it to Subject: [gambit-list]
How about a header List-Id: gambit-list instead of changing the subject line originated by the list member? (Even MS Outlook can be told to filter on additional mail headers.)
Regards Thomas
-
hafner＠sdf-eu.org -
Marc Feeley -
Thomas Hafner