SQLite ↔ Application Threads: Interoperability of sqlite3_interrupt and Busy Timeout for Graceful Cancellation

Goal

To determine how SQLite’s interrupt and busy‑timeout mechanisms cooperate when a statement is blocked on a write-ahead‑logging (WAL) lock, and whether an interrupt can reliably abort such a query.

Constraints & Uncertainty

The SQLite API specifies that sqlite3_interrupt sends a cancellation request to the thread executing the current statement, and that sqlite3_busy_timeout sets a per‑connection wait limit for lock acquisition. However, the interaction between these two mechanisms is not fully documented, particularly when the lock is a WAL checkpoint or a shared‑cache lock. In practice, some builds appear to honor the interrupt, while others delay or ignore it until the lock is released.

Open Questions

1. When a SELECT is blocked waiting for a WAL lock, does sqlite3_interrupt immediately cause the API call to return SQLITE_INTERRUPT, or does it wait until the lock is released?
2. Does setting a busy timeout on the same connection affect the behavior of sqlite3_interrupt during a WAL lock wait?
3. Are there specific SQLite compile options or build configurations that alter the reliability of interrupt handling in this scenario?