-
Notifications
You must be signed in to change notification settings - Fork 275
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
Periodically able to cause moved functions to fail delattr() #98
Comments
Original comment by Joshua Harlow (Bitbucket: harlowja, GitHub: harlowja): Another example occurrence:
|
Original comment by Alex Gaynor (Bitbucket: alex_gaynor, GitHub: Unknown): The problem is |
Original comment by Joshua Harlow (Bitbucket: harlowja, GitHub: harlowja): A simple example that can be used to test this: http://paste.ubuntu.com/8509049/ Eventually this will get
|
Original comment by Alex Gaynor (Bitbucket: alex_gaynor, GitHub: Unknown): It's not immediately obvious to me that the import lock is the right thing to hold here, the semantics around the import lock weird me out in general. I think each |
Originally reported by: Joshua Harlow (Bitbucket: harlowja, GitHub: harlowja)
When running a piece of threaded code that directly uses
six.moves.$XYZ
:For example:
https://github.com/openstack/taskflow/blob/master/taskflow/examples/jobboard_produce_consume_colors.py
I am periodically able to trigger an unusually occurrence with-in six (it doesn't occur on every run, but once every ~20 runs of the above example).
Is it possible for the six.moves.xrange attribute to disappear somehow when running from daemon threads (although those daemon threads are joined on by the parent). Perhaps there is some underlying issue with the above six code?
This is with six==1.7.3 (if that matters).
Full environment @ http://paste.ubuntu.com/8495305/
The text was updated successfully, but these errors were encountered: