sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD

Deon Brewis
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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD

Richard Hipp-3
On 8/14/19, Deon Brewis <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD

Deon Brewis
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 <[hidden email]> On Behalf Of Richard Hipp
Sent: Wednesday, August 14, 2019 6:19 AM
To: SQLite mailing list <[hidden email]>
Subject: Re: [sqlite] sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD

On 8/14/19, Deon Brewis <[hidden email]> 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
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users