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”

“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

Reply via email to