Date: Sat, 18 May 2013 14:31:12 -0700 From: Matt Birkholz <m...@birkholz.chandler.az.us>
That is somewhat the opposite of the GIO interface, whose _async functions return immediately. A callback signals when the requested operation is finished. Thus the main thread is free to do its thing. The callback is short, just collects results. There is no need to run the whole system, thread-switching, inside another mainloop's _progress_handler... ick. Sqlite3 is not a generic event dispatch loop. The purpose of its progress handler is to let you run an event dispatch loop periodically so that other threads/event handlers have a chance to when sqlite3 is spending a lot of time on the CPU to process a long query. I don't know anything about GIO, but presumably the callbacks in its case should only wake a Scheme thread or something. In that case, perhaps it is best to leave thread timer interrupts disabled on entry to the callback. The callback implementation I attached preserves the set of interrupts enabled from C to the Scheme callback, so if you disable thread timer interrupts whenever Scheme passes control to the GIO main loop and only re-enable them on some re-entries into Scheme, then there should be no problem of threads switching in the GIO callbacks, provided you limit what the callbacks themselves do. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
