Intended use is to cancel long running SQLITE background operations on other threads if the user needs UI responsiveness on the main thread. Even though the operations are background, we need the CPU & disk back for the user. Once the user becomes idle again, the background operations restart.
My concern is that SQLITE_CONFIG_SINGLETHREAD implies no mutexes. I don't know if it is possible to correctly implement sqlite3_interrupt() without a mutex on all platforms that SQLITE runs on. - Deon -----Original Message----- From: sqlite-users <sqlite-users-boun...@mailinglists.sqlite.org> On Behalf Of Richard Hipp Sent: Wednesday, August 14, 2019 6:19 AM To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Subject: Re: [sqlite] sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD On 8/14/19, Deon Brewis <de...@outlook.com> wrote: > 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 The sqlite3_interrupt() interface is intending to stop a long-running query, usually by a single handler in response to the user pressing Ctrl-C or similar. This works regardless of compile-time options. What is your intended use of sqlite3_interrupt() that compile-time options matter? -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
