> According to http://www.sqlite.org/c3ref/interrupt.html > process but will not be aborted if it is quite advanced: > > “If an SQL operation is very nearly finished at the time > when sqlite3_interrupt() is called, then it might not have an opportunity to > be > interrupted and might continue to completion.”
I had read that but it seems we disagree on the definition of "nearly finished" ;-) : it can take more than 20s (on an admittedly slow device) between the call to interrupt and completion. > Also: > ”A call to sqlite3_interrupt(D) that occurs when there are no running SQL > statements is a no-op and has no effect on SQL statements that are started > after the sqlite3_interrupt() call returns.” I have tried calling sqlite3_interrupt in a while loop for as long as the thread is running and that's not returning earlier so it is not a no-op thing > The safest solution is to have only ONE threat to deal with > the database. Trust me I'd like that ;-) unfortunately that's not an option given the response times... Do you think there would be any proper places to add CHECK_FOR_INTERRUPT calls to the FTS3 code to improve the issue? Best regards, Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
