Re: [sqlite] sqlite3_interrupt() for controlled interruption

2013-12-03 Thread Igor Tandetnik

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


Re: [sqlite] sqlite3_interrupt() for controlled interruption

2013-12-03 Thread Chen, Mi
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 from another thread

2007-01-31 Thread drh
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_interruptt=1c=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]
-



Re: [sqlite] sqlite3_interrupt()

2006-08-24 Thread drh
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]
-



RE: [sqlite] sqlite3_interrupt()

2006-08-24 Thread Rob Richardson
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()

2006-08-24 Thread drh
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()

2006-08-24 Thread Rob Richardson
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()

2006-08-24 Thread Rob Richardson
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() and threads

2006-07-26 Thread Jens Miltner


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.


/jum



Re: [sqlite] sqlite3_interrupt() and threads

2006-07-25 Thread Martin Jenkins

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


RE: [sqlite] sqlite3_interrupt() and threads

2006-07-25 Thread Rob Richardson
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

2006-07-25 Thread Michael Scharf

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

2006-07-25 Thread Rob Richardson
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

2006-07-25 Thread Rob Richardson
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

2006-07-25 Thread Michael Scharf

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

2006-07-25 Thread drh
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]



[sqlite] unsubscribe me please RE: [sqlite] sqlite3_interrupt() and threads

2006-07-25 Thread Shi, Chunde CTR DISA PEO-C2C
 
 
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]