Keith Medcalf wrote > What are you trying to accomplish? Perhaps what you really want is a > progress callback?
I'm trying to write a function to run a query with a timeout. If the timeout expires, the query must stop execution within a "reasonable" amount of time. To use a progress callback, it sounds like I'd have to choose a small enough N and poll some kind of "timed out" flag, which sounds undesirable. If instead of sqlite3_interrupt, we had sqlite3_begin_interrupt and sqlite3_end_interrupt, that would meet my needs a lot better. Then I would just do the following: 1. Have thread 1 call sqlite3_step. 2. Have thread 2 sleep for whatever timeout, then call sqlite3_begin_interrupt. 3. Once sqlite3_step returns, have thread 1 signal thread 2. 4. Have thread 2 call sqlite3_end_interrupt. Then there would never be a race condition because the interrupt remains in effect even while there are no running statements. Alternatively, having some sort of object to pass into sqlite3_step would also work, as then I could just call some sort of cancel method on that object and have it interrupt that call only. -- 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
