-
Notifications
You must be signed in to change notification settings - Fork 858
Multithreading fixes #288
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
Closed
Closed
Multithreading fixes #288
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
a33dac0
Multithreading support for time() decorators
haizaar 263e2b4
Installing futures package for Python 2.x
haizaar e4969a5
Fixing text environment for Py27 multithread
haizaar 40fdecc
Py2.x unittest compatability
haizaar efc33da
Merge branch 'master' of github.com:haizaar/client_python
haizaar 2bb344d
pypy needs futures for testing as well
haizaar 1807d22
Ensuring that different instances of timer do not interfere
haizaar 6f32ab9
Python2.6 compliance
haizaar b95fc83
Python2.6 compliance take 2
haizaar File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this safe for reentrant use within the same thread?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have a point here -
local()returns reference to the same object within a thread and therefore it will work incorrectly, particularly for nested timers or regular timers in async code. I'm thinking about usingid(self)as a local storage key.What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If
id(self)would work, then we would be able to store in theselfdirectly as it's just the memory address ofself.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will bring us back to the original problem when a single instance of timer used in different threads.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point is that
id(self)doesn't help, as you wouldn't be seeing a race in the first place if that worked. So this doesn't fix reentrancy. We may need a stack here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, lets define the problem :)
Having
The original issue is that:
Produces wrong timings when
f()is called simultaneously from different threads. My last code solves inter thread issue using TLS, and usesid(self)as TSL key to support multiple timer instances within a thread. Such that bothf()andg()(below) workAnd both
f()andg()cases are covered with tests.Now, what do you refer as reentrancy? This? -
This will work as well, since each call to
time()will produce different instances of the_Time()with distinctid(self).P.S. I actually think that the better and simpler idea is to rework both decorator and context manager to use function closure to record the start time. It will be also a bit faster IMHO. I need to think whether its possible to implement it without changing the
time()semantics.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reentrant means that the function calls itself, e.g.:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the use case?
Recursion like this?
Then no,
_Timeris not reentrant. But neither is the current implementation (as in master).