sqlite3_interrupt is documented as: “It is safe to call this routine from a thread different from the thread that is currently running the database operation”
SQLITE_CONFIG_SINGLETHREAD is documented as: “puts SQLite into a mode where it can only be used by a single thread” Which one wins 😉? i.e. Can we call sqlite3_interrupt from a secondary thread in a SQLITE_CONFIG_SINGLETHREAD environment? (And can we have a doc clarification on this). Secondly, regardless of the above answer - from a technical perspective, sqlite3_interrupt is implemented as: volatile int isInterrupted; /* True if sqlite3_interrupt has been called */ … db->u1.isInterrupted = 1; However, even though it’s a volatile int, it doesn’t have any kind of memory fence around it. So reads and writes to it can be re-ordered out of existence or into undefined behavior. This is probably undesired. - Deon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
