Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > This has nothing to do with releasing/aquiring the GIL around > sqlite3_prepare, though.
You mean, it doesn't make things worse, but I believe they do (even if so only slightly). If you have two threads simultaneously attempting an execute on a cursor, one will run into the prepare. That thread will (now) release the GIL, allowing the second thread to run into the prepare. That thread will replace the statement object in the cursor, so when the first thread returns, the statement has changed underneath, and it will associate any return code with the incorrect statement object. In this form, this can't currently happen. Without detailed review, I can readily believe that there are many other cases where a False check_same_thread can give surprising results. > They're there for all other nontrivial SQLite API calls (sqlite3_step, > sqlite3_reset, sqlite3_open, sqlite3_finalize and also already for the > "BEGIN"/"COMMIT" and "ROLLBACK" versions of sqlite3_prepare in connection.c. On the grounds that the code is already full of these GIL release calls, I'll approve this additional one. I encourage you to review the entire issue, though, and document somewhere what promises are made under what conditions. Then a later review can validate that the promises are really kept. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3846> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
