> From: Taylor R Campbell <campb...@mumble.net> > Date: Sat, 18 May 2013 23:31:23 +0000 > > [...] > Sqlite3 is not a generic event dispatch loop. The purpose of its > progress handler is to let you run an event dispatch loop [...]
Actually the documentation says "to keep a GUI updated". The problem with expanding that into "run an event dispatch loop" is that interleaving two mainloops is like serving two masters: one is always blocking when the other wants to run. If you are saying the library never has to block on any channels(?), then _progress_handler may do fine. It may even be acceptable if it blocks Scheme just a little(?). I can add a with-other-threads-allowed procedure that the "progress" callback can use to allow thread switching, much as you did in microcode-callback. > The callback implementation I attached preserves the set of interrupts > enabled from C to the Scheme callback, Why do you mention this in particular? It seems odd. The enabled interrupts at the point of a callback are always /gc-ok. There is no point in saving them. Interrupts have to be saved/disabled before the preceding callout, else you will have holes. The callback implementation you attached is mostly about replacing a vector of registered callbacks, O(1), with a red-black tree, O(log n). That and your pre-occupation with the enabled interrupts is... weird. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
