----- Original Message ---- From: Simon [email protected] >However, it seems that some process (that can take >several tens of seconds) in the first >sqlite3_step does not test for >interrupt (resulting in simultaneous uninterrupted >concurrent threads...) According to http://www.sqlite.org/c3ref/interrupt.html process but will not be aborted if it is quite advanced:
“If an SQL operation is very nearly finished at the time when sqlite3_interrupt() is called, then it might not have an opportunity to be interrupted and might continue to completion.” Also: ”A call to sqlite3_interrupt(D) that occurs when there are no running SQL statements is a no-op and has no effect on SQL statements that are started after the sqlite3_interrupt() call returns.” The safest solution is to have only ONE threat to deal with the database. Let me quote famous words: “Threads are evil. Avoid them.” http://www.sqlite.org/faq.html#q6 Regards, Samuel __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
