This repository has been archived by the owner on Nov 5, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 430
multistore_file raises errno.EDEADLK when trying to open credential store #335
Comments
Thanks for the report, we would definitely be receptive to an implementation of your suggested fixes, and today I learned that Python's |
The file-locking notion is still useful for dealing with multiple applications executing simultaneously. Using a multiprocessing lock is feasible, though it would probably need to come from the calling application. A thread lock would be easy, though. This pattern worked well elsewhere in gsutil: multistore_lock = threading.CreateLock()
def UseProcessSafeLock(multiprocessing_lock):
global multistore_lock
multistore_lock = multiprocessing_lock |
thobrla
added a commit
to thobrla/oauth2client
that referenced
this issue
Nov 10, 2015
Fixes googleapis#335 This change fixes a bug where multiple threads and/or processes using multistore_file to access the same backing store could raise IOError errno.EDEADLK to the calling application. Since EDEADLK is a possibility with concurrent access, this change instead causes a fallback to read only mode and refresh credentials if necessary.
thobrla
added a commit
to thobrla/oauth2client
that referenced
this issue
Nov 17, 2015
Fixes googleapis#335 This change fixes a bug where multiple threads and/or processes using multistore_file to access the same backing store could raise IOError errno.EDEADLK to the calling application. Since EDEADLK is a possibility with concurrent access, this change instead causes a fallback to read only mode and refresh credentials if necessary.
thobrla
added a commit
to thobrla/oauth2client
that referenced
this issue
Nov 17, 2015
Fixes googleapis#335 This change fixes a bug where multiple threads and/or processes using multistore_file to access the same backing store could raise IOError errno.EDEADLK to the calling application. Since EDEADLK is a possibility with concurrent access, this change instead causes a fallback to read only mode and refresh credentials if necessary.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
multistore_file claims to be process and thread safe, but if multiple threads try to refresh credentials simultaneously, it can result in an exception like the stack trace at the bottom of this issue.
multistore_file catches errno.ENOSYS and errno.ENOLCK already. The simple fix would be to add EDEADLK to this list, since multiple threads opening the file can definitely result in this error. Additionally, it might be useful to add an actual Python lock to protect this access, which would help a lot when threads (or, optionally, child processes) contend for this resource on startup.
Encountered exception while copying:
The text was updated successfully, but these errors were encountered: