Re: [MIT-Scheme-devel] sqlite3

[Taylor R Campbell]

   Date: Sat, 18 May 2013 14:31:12 -0700
   From: Matt Birkholz <address@hidden>

   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.