Consider the following pseudo-code.
void interrupt_timeout(sqlite3* db, int timeout) {
sleep(timeout);
sqlite3_interrupt(db);
}
int main() {
sqlite3* db = sqlite3_open_v2(...);
sqlite3_stmt* stmt = sqlite3_prepare_v2(db, ...);
...
pthread_create(interrupt_timeout, db, timeout);
int rv = sqlite3_step(stmt);
...
}
(I know this doesn't work properly if sqlite3_step doesn't time out, but it
suffices for this example.)
For the purposes of this example, let's suppose that the call to
sqlite3_step takes a while. According to the docs, "New SQL statements that
are started after the running statement count reaches zero are not effected
by the sqlite3_interrupt()." But for very small timeouts, it's possible that
sqlite3_interrupt gets executed /before/ sqlite3_step ever gets called, in
which case sqlite3_step runs to completion no matter how long it takes.
Am I missing something? Is there another way to leverage sqlite3_interrupt
that doesn't have this race condition? What exactly is meant by "running
statements"? Is it statements that are in the middle of a call to
sqlite3_step? Statements that have been stepped, but not yet reset?
Something else?
--
Sent from: http://sqlite.1065341.n5.nabble.com/
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
