-
Notifications
You must be signed in to change notification settings - Fork 35
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
Working with Threads #38
Comments
Hello, James. global _pg_iri, _pg_driver, _pg_param if _pg_iri is None: from . import iri as _pg_iri from . import driver as _pg_driver from . import clientparameters as _pg_param But I think, I will be relatively easy to make support of thread safety for model "connection per thread" |
Hmm. Yeah, that was silly of me. Could you see if this fixes your issue:
Having _pg_iri last should make the race condition benign. |
Thank you I will try if it is necessary |
Yeah, connection per thread should just work. |
Hello, I would like to ask if it is still true that to establish and close connection inside threads is OK? |
Should be. However, when closing a Connection, only one thread should be performing the operation. |
Hm, not very clear to me. I have one main thread that creates and starts child threads in unpredictable time (all at ones, one after another, overlapping in some way). In each child thread I create separate db connection by calling
|
If you rely on garbage collection, I believe a resource warning will be emitted by Python's socket module.
No. The driver is not thread aware and there is no communication between connections. You can either If each thread has its own Connection, you're safe. |
Thanks for explanation. Yes I establish and close connection explicitly in thread function (not passing to thread) so I will early find out if I am safe :) |
Use the issue as documentation. |
Hello, after one year with happy usage of model "connection per thread" new error sometimes rises. It looks like it always happens at the very beginning when the multiple threads start at the same time. The error looks like this:
Can it be some race condition with importing pypostgresql library? Should be imported in main thread or child thread? |
_pg_param is the last global initialized and _pg_iri is the first, so I think so. Naturally, this will only occur if you're using postgresql.open. Using Connectors directly instead of postgresql.open is advisable for most applications. Workarounds:
The deferred imports, likely, don't have any value these days. They were used to avoid unused modules in applications that used Connectors directly. Today, the primary advantage this has is dodging bitrot in _pg_param. The third workaround is what I plan to apply. Remaining synchronization issues should be handled by Python's import locks and object level locks in nogil Pythons. |
Thanks for advice we have changed open() with driver.connect() and problem is gone :) |
Add a section to the driver documentation about working with threads. Most drivers offer thread safety, but driver.pq3 does not.
Discuss: one connection per thread, synchronizing using a queue, and explicit locking.
The text was updated successfully, but these errors were encountered: