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
Add a timeout functionality to common locking operations #51565
Comments
Here is a patch which adds a timeout feature to the locking operations
The timeout duration is expressed in microseconds at the C API level, At the C level, the max timeout is PY_TIMEOUT_MAX (in microseconds). The The patch contains both a POSIX implementation and a Windows |
This patch adds some docs and comments. It also adds the feature in the |
I don't object strongly, but since locks are "supposed" to be held for Given that it's hard to pick a timeout in most cases anyway, I think That said, I have no objections at all to adding an internal timeout |
I don't see how it's an objection. If you have a condition variable you
What do you mean by thread interruption? Cancellation?
Well, it's pretty basic functionality provided by the underlying OS (and it's safer than thread cancellation ;-)) |
The cv's timeout stops waiting for the cv to be notified, but then it
Yes, sorry, I was using the Java term, which isn't particularly accurate.
Fair enough. |
Updated patch against py3k. |
Updated patch against newest py3k. |
Above here, it says, "It defines the following constant and
Do we want to document what this value is likely to be? Or guarantee I believe we can support arbitrary values here, subject to floating
Since there are now 2 optional arguments, this needs to be updated.
You might mention that "lock.acquire(timeout=0)" is equivalent to
s/and as long as the lock cannot be acquired./and return False if the
I think this deserves a comment that it's not the same as
This should probably be the same as the typical value for _thread.TIMEOUT_MAX.
Why is this change here? (Mostly curiosity)
Please add this to the documentation.
This is just a sanity-check that a successful acquire finishes in a
I believe it's possible for this comparison to return false, but for $ cat test.c
#include <stdio.h>
#include <limits.h>
int main() {
double d_ll_max = (double)LONG_LONG_MAX;
if (d_ll_max > LONG_LONG_MAX)
printf("Bigger\n");
if (d_ll_max == LONG_LONG_MAX)
printf("Equal\n");
printf("%lld %lf %lld\n", LONG_LONG_MAX, d_ll_max, (long long)d_ll_max);
return 0;
} $ ./test
Equal
9223372036854775807 9223372036854775808.000000 -9223372036854775808 Unfortunately, that overflowing cast back to long long is undefined
Use ==0 now that this in a real integer?
Can (microseconds+999) overflow?
Famous last words. ;) (Not saying you should change anything)
Pull this into a helper function so it's not duplicated between the
|
Here is a new patch fixing most of your comments. A couple of answers:
I'm a bit wary of this, because we can't test it properly.
Because 1e100 would raise OverflowError :)
Ok, I've replaced it with the following which should be ok:
Indeed it can (I sincerely hoped that nobody would care...). |
Updated patch against current py3k. |
Thanks, looks good. Sorry for the delay. |
Thank you! Checked in in r80071. |
While you are at it, you might want to submit the patch from http://bugs.python.org/issue850728 as well. It adds timeouts for semaphores. :) |
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: