[SERVER-54344] Interruptible's Atomic timer parameter is not typesafe Created: 05/Feb/21 Updated: 29/Oct/23 Resolved: 13/Jul/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 5.1.0-rc0, 4.4.24, 5.0.20 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Alex Li |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | save-for-alex, servicearch-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v5.0, v4.4
|
||||||||||||
| Sprint: | Service Arch 2021-07-12 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
|
| Comments |
| Comment by Githook User [ 19/Jul/23 ] |
|
Author: {'name': 'Alex Li', 'email': 'alex.li@mongodb.com', 'username': 'lia394126'}Message: (cherry picked from commit f4943eead1c1a2fdd3d72bfec1ad966911019359) |
| Comment by Githook User [ 12/Jul/23 ] |
|
Author: {'name': 'Alex Li', 'email': 'alex.li@mongodb.com', 'username': 'lia394126'}Message: (cherry picked from commit f4943eead1c1a2fdd3d72bfec1ad966911019359) |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 12/Jul/21 ] |
|
Author: {'name': 'Alex Li', 'email': 'alex.li@mongodb.com'}Message: |
| Comment by Billy Donahue [ 05/Feb/21 ] |
|
Luckily the waitTimer parameter of waitForConditionOrInterrupt is never actually used. I feel like this isn't really a core capability of Interruptible. Maybe we can just revert It could be rather an add-on nonmember function to poll an Interruptible and provide feedback on its timer progress, which might use an atomic, or it might use another synchronization technique to update the waitTimer that's more useful for that callsite. Another API consideration is that there's a strong preference for keeping callables as final parameter so that lambdas can let their freak flag fly and take up a few lines without having a tag-along trailing parameter following them. |