[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] sqlite3
From: |
Taylor R Campbell |
Subject: |
Re: [MIT-Scheme-devel] sqlite3 |
Date: |
Fri, 17 May 2013 03:13:38 +0000 |
User-agent: |
IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1.1 |
Date: Thu, 16 May 2013 20:58:54 +0000
From: Taylor R Campbell <address@hidden>
Interrupt-safety is not quite done yet: it needs to integrate with the
thread system using sqlite3_interrupt and sqlite3_progress_handler so
that ^G at the REPL can usefully interrupt a long-running query, and
other Scheme threads can get a chance to run during a long-running
query.
This will require a mechanism for calling back into Scheme and letting
the Scheme stack swap around to switch threads without getting the C
stack mixed up. I hoped the ffi callback mechanism might already do
this, but evidently not; instead interrupts are just disabled on entry
to callbacks, and the world probably comes crashing down if you try to
enable them.
Scheme48 has a working implementation of this. When C calls into
Scheme, it passes Scheme a token and a return-to-c continuation to
which Scheme must return the token. Any Scheme thread can return to
the return-to-c continuation, but since the Scheme stack can swap
around, the first thread to return to it might not match the token
that was most recently passed to Scheme. In that case, C calls back
into Scheme again saying `nope, switch threads until I get the right
token'.
- [MIT-Scheme-devel] sqlite3, Taylor R Campbell, 2013/05/16
- Re: [MIT-Scheme-devel] sqlite3,
Taylor R Campbell <=
- [MIT-Scheme-devel] sqlite3, Matt Birkholz, 2013/05/18
- Re: [MIT-Scheme-devel] sqlite3, Taylor R Campbell, 2013/05/18
- Re: [MIT-Scheme-devel] sqlite3, Matt Birkholz, 2013/05/19
- Re: [MIT-Scheme-devel] sqlite3, Taylor R Campbell, 2013/05/19
- Re: [MIT-Scheme-devel] sqlite3, Matt Birkholz, 2013/05/19
- Re: [MIT-Scheme-devel] sqlite3, Taylor R Campbell, 2013/05/19
- Re: [MIT-Scheme-devel] sqlite3, Matt Birkholz, 2013/05/27