Re: [sqlite] sqlite3_interrupt and explicit transactions
On Monday, 16 December, 2019 12:17, Jesse Rittner wrote: > I have a few questions about how sqlite3_interrupt interacts with > explicit transaction operations. The docs say that "If the interrupted > SQL operation is an INSERT, UPDATE, or DELETE that is inside an > explicit transaction, then the entire transaction will be rolled back > automatically." Less than 3 minutes of testing and code analysis reveals: > 1. Can sqlite3_interrupt interrupt a call to BEGIN or its variants (BEGIN > IMMEDIATE and BEGIN EXCLUSIVE)? If so, is the transaction automatically > "rolled back" in this case? No. Setting transaction mode and autocommit mode is not an interruptible operation. See * below. >2. What about an interrupt during an explicit call to COMMIT or ROLLBACK? No. Re-enabling autocommit is not an interruptible operation. See * below. >3. What is the behavior with regard to savepoints? Will the outermost >transaction get rolled back if an operation gets interrupted? Yes. You can always determine whether a transaction is in process on a database connection by calling sqlite3_get_autocommit. sqlite3_interrupt sets an isInterrupted flag on a connection. When sqlite3_exec is called on a non-running statement (ie, for the first time) AND isInterrupted is set AND there are no running statements the isInterrupted flag is reset. The statement will then commence running if isInterrupted is clear, and not run if isInterrupted is set. When a VDBE program is executing it checks after certain opcodes if the isInterrupted flag is set and if it is the executing statement (and its containing transaction) are aborted. *Note that in order for an interrupt to have any effect, the VDBE program must be running. If the VDBE program is "paused" (as in the statement has returned a row and is waiting for the next sqlite3_exec) it will not be interrupted until you call sqlite3_exec on that statement the next time. The isInterupted flag will remain set until all "busy" statements on the connection have been interrupted. That means that if you start a statement executing and do not step it to completion (or reset it) the isInterrupted will remain in effect until you do, effectively precluding your ability to execute any statements whatsoever on that connection until the connection is no longer busy, as the purpose of the sqlite3_interrupt is to cancel pending operations on a connection and return it to a non-busy state. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_interrupt and explicit transactions
On 16 Dec 2019, at 7:16pm, Jesse Rittner wrote: > 1. Can sqlite3_interrupt interrupt a call to BEGIN or its variants (BEGIN > IMMEDIATE and BEGIN EXCLUSIVE)? If so, is the transaction automatically > "rolled back" in this case? > 2. What about an interrupt during an explicit call to COMMIT or ROLLBACK? > 3. What is the behavior with regard to savepoints? 1. If BEGIN is interrupted, no transaction is started. 2. This results in the equivalent of ROLLBACK 3. This results in the equivalent of ROLLBACK. Savepoints are lost. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3_interrupt and explicit transactions
I have a few questions about how sqlite3_interrupt interacts with explicit transaction operations. The docs say that "If the interrupted SQL operation is an INSERT, UPDATE, or DELETE that is inside an explicit transaction, then the entire transaction will be rolled back automatically." 1. Can sqlite3_interrupt interrupt a call to BEGIN or its variants (BEGIN IMMEDIATE and BEGIN EXCLUSIVE)? If so, is the transaction automatically "rolled back" in this case? 2. What about an interrupt during an explicit call to COMMIT or ROLLBACK? 3. What is the behavior with regard to savepoints? Will the outermost transaction get rolled back if an operation gets interrupted? -- Sent from: http://sqlite.1065341.n5.nabble.com/ ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD
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 On Behalf Of Richard Hipp Sent: Wednesday, August 14, 2019 6:19 AM To: SQLite mailing list Subject: Re: [sqlite] sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD On 8/14/19, Deon Brewis 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
Re: [sqlite] sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD
On 8/14/19, Deon Brewis 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] sqlite3_interrupt vs. SQLITE_CONFIG_SINGLETHREAD
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
[sqlite] sqlite3_interrupt
Hi all, I was looking to the sqlite3_interrupt to make my application closing faster without waiting for long standing DB operation. I read in the documentation that should not be a problem to call it during insert update or delete: if transaction is running is automatically rolled back. Do you think there's some extra care I have to deal with before using interrupt function? Do you have some experience in using it during read/write operation on DB? regards ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_interrupt() for controlled interruption
This is exactly what I need. Thanks very much! Mi Chen -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Igor Tandetnik Sent: Tuesday, December 03, 2013 7:46 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] sqlite3_interrupt() for controlled interruption On 12/3/2013 9:26 PM, Chen, Mi wrote: > I want to use sqlite3_interrupt() to interrupt the statement that is > executing sqlite3_step() for the first time in the worker. It is mutex > protected so I already make sure that when sqlite3_interrupt() is called, my > worker thread is running sqlite3_step()... > > However, the current sqlite3_interrupt() behavior is to interrupt all the > statements, including the ones that I suspended and running half-ways in the > background. I could make a separate database connection for each query, but > the ability for them to share data (e.g., temp tables) were limited. See if sqlite3_progress_handler helps. A progress handler only cancels one sqlite3_step() call. -- Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_interrupt() for controlled interruption
On 12/3/2013 9:26 PM, Chen, Mi wrote: I want to use sqlite3_interrupt() to interrupt the statement that is executing sqlite3_step() for the first time in the worker. It is mutex protected so I already make sure that when sqlite3_interrupt() is called, my worker thread is running sqlite3_step()... However, the current sqlite3_interrupt() behavior is to interrupt all the statements, including the ones that I suspended and running half-ways in the background. I could make a separate database connection for each query, but the ability for them to share data (e.g., temp tables) were limited. See if sqlite3_progress_handler helps. A progress handler only cancels one sqlite3_step() call. -- Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3_interrupt() for controlled interruption
I run into an issue where I have a database connection that have quite a few
queries that were suspended due to managed priorities...
I have two threads, the control thread (UI), and a sqlite3 worker thread.
I want to use sqlite3_interrupt() to interrupt the statement that is executing
sqlite3_step() for the first time in the worker. It is mutex protected so I
already make sure that when sqlite3_interrupt() is called, my worker thread is
running sqlite3_step()...
However, the current sqlite3_interrupt() behavior is to interrupt all the
statements, including the ones that I suspended and running half-ways in the
background. I could make a separate database connection for each query, but the
ability for them to share data (e.g., temp tables) were limited.
So I wonder if I can call sqlite3_clear_interrupt() or similar in my worker
thread to limit the scope of statements being interrupted, so that only the
currently "executing" queries would be disposed... I understand it is kind of
dangerous to clear the flag in any other situation if it is not controlled, but
I only have one worker thread per db handle.
void sqlite3_clear_interrupt(sqlite3 *db)
{
db->u1.isInterrupted = 0;
}
Any thoughts would be helpful. Thanks!
Mi Chen
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3_interrupt() can interrupt query started after it's return
Hi,
I'm using sqlite as the sql driver of Qt 4.
I have a connection created in a thread and i call sqlite3_interrupt()
from another one.
It's working great, perhaps i have not the behavior that say the doc :
"A call to sqlite3_interrupt() has no effect on SQL statements that
are started after sqlite3_interrupt() returns."
I have a code like that :
void UICollection::executeQuery()
{
mContainer.sqlModel()->stopQuery(); // this member call the
sqlite3_interrupt()
PageDatas page = mContainer.datas().pages().value( currentPageId() );
int viewId = page.views().first();
PageQueryGenerator generator( &mContainer );
QString sql = generator.generatedQuery( page.internalId(), viewId );
mContainer.sqlModel()->setQuery( sql );
}
In the generator object, there is a query that get all fields from a
table, this query is interrupted by the previous stopQuery() call.
That's not what i want :(
Is it a know problem, or does it exists a workaround ?
PS: All my queries are "select" statements.
Regards, Thanks, Filipe
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite3_interrupt and transactions
Greetings!
I need to be able to interrupt a long-running query within a transaction. The
question is: is it possible that changes made previously in this transaction
will be affected?
Example pseudo-code:
1. BEGIN IMMEDIATE
2. INSERT INTO x (x) VALUES ('y');
3. SELECT long_running_query
4. *from another thread* interrupt SELECT via progress handler or
sqlite3_interrupt
5. // ignore interrupted return code
6. COMMIT
7. SELECT x FROM x WHERE x = 'y' (will it be there?)
When I run a simple example as described above, it works - the transaction is
not ruined by interrupt. On the other hand, this case is not covered in the
documentation; specs only say that "If the interrupted SQL operation is an
INSERT, UPDATE, or DELETE that is inside an explicit transaction, then the
entire transaction will be rolled back automatically".
So, is it safe to assume that "If the interrupted SQL operation is a SELECT
that is inside an explicit transaction, then the transaction is not affected"?
Thanks for your help!
Igor
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite3_interrupt from another thread
Roger Binns <[EMAIL PROTECTED]> wrote: > > We had an earlier discussion about calling sqlite3_interrupt from > another thread, which wasn't possible at the time: > > It looks like the code is fixed for 3.3.12 (and possibly earlier). I > just wanted to double check that it is now officially safe to call from > another thread. The main documentation doesn't mention anything either way. > Go to http://www.sqlite.org/cvstrac/search and do a search for sqlite3_interrupt in tickets and in check-ins. The result is http://www.sqlite.org/cvstrac/search?s=sqlite3_interrupt&t=1&c=1 From this we see that that sqlite3_interrupt() can be called from a separate thread as of check-in [3336] on 2006-07-26 associated with ticket #1897. That was first delivered in version 3.3.7. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] sqlite3_interrupt from another thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We had an earlier discussion about calling sqlite3_interrupt from another thread, which wasn't possible at the time: http://article.gmane.org/gmane.comp.db.sqlite.general/20427 It looks like the code is fixed for 3.3.12 (and possibly earlier). I just wanted to double check that it is now officially safe to call from another thread. The main documentation doesn't mention anything either way. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFwUICmOOfHg372QQRAnJnAKDXpjxOhbXtMak9EVoDjXBPfmG7fACfcwUl nOWwJ6XrTmXzNYVg/PqFyv8= =1+/+ -END PGP SIGNATURE- - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] sqlite3_interrupt() works
Greetings! After installing SQLite 3.3.7 and making sure I was passing the correct pointer to sqlite3_interrupt(), I got it to work. Rob Richardson RAD-CON INC.
RE: [sqlite] sqlite3_interrupt()
I think I've found the problem.
The next step in debugging was to find the actual sqlite3 library calls
I was making, just to make sure the delay wasn't somewhere else in my
code. Here's the trace statements:
GetTrendData() started at Thu Aug 24 16; sqlite object is at 056B9570.
select tag_key,value,datetime(value_timestamp, 'localtime') from
trend_view where trend_key=1 and value_timestamp <=
julianday('2006-08-22 16C
SqlOpen(): First sqlite3_step() called at Thu Aug 24 16:30:52 2006
; sqlite object is at 056C20E0.
Interrupt requested at Thu Aug 24 16:30:54 2006
for object at 056B9570.
CSqlOpen(): Back from first sqlite3_step() call at Thu Aug 24 16:32:04
2006
; sqlite object is at 056C20E0.
GetTrendData() finished at Thu Aug 24 16
The object pointer reported in the second statement is not the same as
the one in the first statement. The second statement's pointer is the
one that was used in the call to sqlite3_prepare(). The
sqlite3_interrupt() pointer had better be the same as the one in
sqlite3_prepare(), and it wasn't.
Bottom line: I was trying to interrupt the wrong sqlite3 object.
Once I figure out how to get the correct sqlite3 object to use in the
interrupt call, I'll let you know how it works.
Rob Richardson
RAD-CON INC.
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
RE: [sqlite] sqlite3_interrupt()
Dr. Hipp,
Thank you very much for your earlier assistance. As you suggested, I
downloaded the version 3.3.7 source code and built it into a static
library. My application now correctly reports that it is using version
3.3.7.
But sqlite3_interrupt() still seems to be doing nothing. I added TRACE
statements to my code to show the times things happened, and I included
the value of the pointer to the sqlite3 object that was being used when
the query starts and as the argument to sqlite3_interrupt():
GetTrendData() started at Thu Aug 24 16:03:54 2006
; sqlite object is at 056B89E0.
select tag_key,value,datetime(value_timestamp, 'localtime') from
trend_view where trend_key=1 and value_timestamp <=
julianday('2006-08-22 16:01:41.000', 'utc') order by value_timestamp
desc
Interrupt requested at Thu Aug 24 16:03:57 2006
for object at 056B89E0.
GetTrendData() finished at Thu Aug 24 16:05:07 2006
Rob Richardson
RAD-CON INC.
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] sqlite3_interrupt()
"Rob Richardson" <[EMAIL PROTECTED]> wrote: > Dr. Hipp, > > Thank you very much for your earlier assistance. As you suggested, I > downloaded the version 3.3.7 source code and built it into a static > library. My application now correctly reports that it is using version > 3.3.7. > > But sqlite3_interrupt() still seems to be doing nothing. I added TRACE > statements to my code to show the times things happened, and I included > the value of the pointer to the sqlite3 object that was being used when > the query starts and as the argument to sqlite3_interrupt(): > Can you run your program in a debugger? The sqlite3_interrupt() routine should set the sqlite3.u1.isInterrupted flag. That flag is then tested at various points in the file vdbe.c (whereever you see the macro CHECK_FOR_INTERRUPT) and if it is true, the execution of the statement should stop. The flag is reset once the statement completes. Run your program in a debugger and try to figure out what is going wrong. Let me know if you find a bug in SQLite. (It works when I test it) -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] sqlite3_interrupt()
Dr. Hipp, Thanks for your reply. The question of which version I'm using is up in the air right now. I threw a call to sqlite3_libversion() into my application, and it returned "3.2.1". I asked our lead developer (who's in Indiana while the rest of us are just west of Cleveland, OH) what version we should have, and he said 3.3.5. He sent the source code. I opened my existing copy of sqlite3.h and saw that SQLITE_VERSION was set to "3.3.5". Yet, when I my application, I get 3.2.1. I deleted all copies of sqlite3.lib and sqlite3.dll from my machine, rebuilt sqlite3 from Visual Studio, and still I get 3.2.1. I have no idea where it's coming from, but it seems to be telling me I'm using an old version of SQLite. RobR - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] sqlite3_interrupt()
"Rob Richardson" <[EMAIL PROTECTED]> wrote: > I have a thread that executes a query that takes about 30 seconds on my > test setup. In the field, the query could take several minutes. The > user needs to be able to stop this query if it was started by accident. > I have a pointer to the sqlite3 object that is running the query inside > my thread. In the main GUI thread of the application, I call > sqlite3_interrupt(), passing it the stored sqlite3 pointer. But after I > do that, the query still stops executing 30 seconds after it started. > The interruption seems to have no effect. Is this expected? How soon > after I issue sqlite3_interrupt() should a long query stop executing? > Or am I doing something wrong? > The query should stop immediately. Are you using the latest version of SQLite that supports calling sqlite3_interrupt() from a separate thread, or an older version that might have problems? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] sqlite3_interrupt()
I have a thread that executes a query that takes about 30 seconds on my test setup. In the field, the query could take several minutes. The user needs to be able to stop this query if it was started by accident. I have a pointer to the sqlite3 object that is running the query inside my thread. In the main GUI thread of the application, I call sqlite3_interrupt(), passing it the stored sqlite3 pointer. But after I do that, the query still stops executing 30 seconds after it started. The interruption seems to have no effect. Is this expected? How soon after I issue sqlite3_interrupt() should a long query stop executing? Or am I doing something wrong? Thank you very much. RobR
Re: [sqlite] sqlite3_interrupt() and threads
Am 26.07.2006 um 01:06 schrieb [EMAIL PROTECTED]: Michael Scharf <[EMAIL PROTECTED]> wrote: Rob, I notice in the documentation that the sqlite3_progress_handler() method is marked "experimental". Is that significant? No idea, that's a question Richard Hipp may answer.. I need to remove the experimental marking. Perhaps somebody could create a ticket to remind me ;-) While you are at it, consider creating an enhancement ticket to allow sqlite3_interrupt to be called from a different thread. Tickets #1897 and #1898. I saw that you already committed code to make sqlite3_interrupt thread-safe, but created a ticket anyway to make sure it's tracked.
[sqlite] unsubscribe me please RE: [sqlite] sqlite3_interrupt() and threads
Chunde Shi [EMAIL PROTECTED] 703 882 1466 703 882 2325 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tue 7/25/2006 7:06 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] sqlite3_interrupt() and threads Michael Scharf <[EMAIL PROTECTED]> wrote: > Rob, > > I notice in the documentation that the sqlite3_progress_handler() method > > is marked "experimental". Is that significant? > > No idea, that's a question Richard Hipp may answer.. > I need to remove the experimental marking. Perhaps somebody could create a ticket to remind me ;-) While you are at it, consider creating an enhancement ticket to allow sqlite3_interrupt to be called from a different thread. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] sqlite3_interrupt() and threads
Michael Scharf <[EMAIL PROTECTED]> wrote: > Rob, > > I notice in the documentation that the sqlite3_progress_handler() method > > is marked "experimental". Is that significant? > > No idea, that's a question Richard Hipp may answer.. > I need to remove the experimental marking. Perhaps somebody could create a ticket to remind me ;-) While you are at it, consider creating an enhancement ticket to allow sqlite3_interrupt to be called from a different thread. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] sqlite3_interrupt() and threads
Rob, I notice in the documentation that the sqlite3_progress_handler() method is marked "experimental". Is that significant? No idea, that's a question Richard Hipp may answer.. Michael -- http://MichaelScharf.blogspot.com/
RE: [sqlite] sqlite3_interrupt() and threads
Michael, I notice in the documentation that the sqlite3_progress_handler() method is marked "experimental". Is that significant? Rob
RE: [sqlite] sqlite3_interrupt() and threads
Great! That looks like exactly what I need. Thanks very much! Rob Richardson RAD-CON INC. -Original Message- From: Michael Scharf [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 10:45 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] sqlite3_interrupt() and threads Hi Richard, I use a progres_handler: http://www.sqlite.org/capi3ref.html#sqlite3_progress_handler I set it up to be called every 1 ticks (2nd argument) or so and I use and the void* to points to a data structure that contains a boolean isCanceled. If another thread wants to cancel the worker thread it sets the isCanceled to true. The progress callback checks the isCanceled and returns 0 if set. Then the query gets aborted... (I'm using this in java and it works just fine) Michael > Thank you for pointing me to that article. That leads to two more > questions: > > What alternative do I have? If I abort the thread that is running the > query, will the query stop? > > And, if sqlite3_interrupt() has to be issued from the same thread that > is using the database, what is it designed to be used for? > > OK, three questions: Is there a way to run sqlite3 queries > asynchronously? > > Thanks again! > > Rob Richardson > Rad-Con, Inc. > > -- http://MichaelScharf.blogspot.com/
Re: [sqlite] sqlite3_interrupt() and threads
Hi Richard, I use a progres_handler: http://www.sqlite.org/capi3ref.html#sqlite3_progress_handler I set it up to be called every 1 ticks (2nd argument) or so and I use and the void* to points to a data structure that contains a boolean isCanceled. If another thread wants to cancel the worker thread it sets the isCanceled to true. The progress callback checks the isCanceled and returns 0 if set. Then the query gets aborted... (I'm using this in java and it works just fine) Michael Thank you for pointing me to that article. That leads to two more questions: What alternative do I have? If I abort the thread that is running the query, will the query stop? And, if sqlite3_interrupt() has to be issued from the same thread that is using the database, what is it designed to be used for? OK, three questions: Is there a way to run sqlite3 queries asynchronously? Thanks again! Rob Richardson Rad-Con, Inc. -- http://MichaelScharf.blogspot.com/
RE: [sqlite] sqlite3_interrupt() and threads
Thank you for pointing me to that article. That leads to two more questions: What alternative do I have? If I abort the thread that is running the query, will the query stop? And, if sqlite3_interrupt() has to be issued from the same thread that is using the database, what is it designed to be used for? OK, three questions: Is there a way to run sqlite3 queries asynchronously? Thanks again! Rob Richardson Rad-Con, Inc.
Re: [sqlite] sqlite3_interrupt() and threads
Rob Richardson wrote: [...] Can sqlite3_interrupt() be called from a different thread than the sqlite3_step() that I want to interrupt, or is there some other mechanism I can use, or is there no way to do this? This came up a couple of weeks ago. I don't have the message here to quote but you can see it at: http://www.mail-archive.com/sqlite-users@sqlite.org/msg16361.html Martin
[sqlite] sqlite3_interrupt() and threads
Greetings! My application will occasionally be called on to execute queries that take several minutes. This will be done from a worker thread so that the user interface remains active. As the query is being executed, the user must be able to respond to alarms. When the user hits F11 to go straight to the alarm screen, the window from which the thread that is running the long query disappears. However, the thread continues. I need to stop the query. The thing that takes the time is the first call to sqlite3_step(). That step is likely to take 5 minutes, and I may need to stop it after 1 minute. The only way I can think of to do that is to call sqlite3_interrupt() from a different thread. However, for regular data access operations, we can't use the same database connection in two different threads. Can sqlite3_interrupt() be called from a different thread than the sqlite3_step() that I want to interrupt, or is there some other mechanism I can use, or is there no way to do this? Thanks very much! Rob Richardson Rad-Con, Inc.
