-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sqlite3 module: Improved concurrency #48096
Comments
I'd really like this change to get into Python 2.6. It's pretty trivial Could somebody please review this and give me an ok to check it in? |
Your patch seems obvious, however:
|
Good that you mention it. During sqlite3_prepare, SQLite can call the
Connections/cursors cannot be shared among Python threads. Well, with If, however, the table is dropped between sqlite3_prepare and |
Asking in the same direction: what is the consequence of this patch when |
Interesting. I was smart enough to not document check_same_thread in the This has nothing to do with releasing/aquiring the GIL around |
Just to be explicit: check_same_thread is unsupported and while it's [In the current pysqlite docs it's not documented at all at the moment, |
You mean, it doesn't make things worse, but I believe they do That thread will (now) release the GIL, allowing the second thread In this form, this can't currently happen. Without detailed review,
On the grounds that the code is already full of these GIL release calls, I encourage you to review the entire issue, though, and document |
Thanks, Martin. Commited as r66414. |
bpo-3854 was created for documenting sqlite3 vs. threads. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: