[SERVER-66036] Improve future validity semantics Created: 27/Apr/22 Updated: 29/Oct/23 Resolved: 06/Sep/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.2.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Matt Diener (Inactive) | Assignee: | Matt Diener (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Service Arch 2022-05-02, Service Arch 2022-05-16, Service Arch 2022-05-30, Service Arch 2022-06-13, Service Arch 2022-06-27, Service Arch 2022-07-11, Service Arch 2022-07-25, Service Arch 2022-08-08, Service Arch 2022-08-22, Service Arch 2022-09-05, Service Arch 2022-09-19 |
| Participants: |
| Description |
|
This is a follow-up to Although the concept of validity can reflect whether a Future has access to a SharedState (or an immediate value in the case of an optimization), out of the box there are many cases where futures remain valid(), when using them is not necessarily valid. For example, `get` does not currently invalidate the pointer to the SharedState/set it to nullptr. |
| Comments |
| Comment by Githook User [ 06/Sep/22 ] |
|
Author: {'name': 'Matt Diener', 'email': 'matt.diener@mongodb.com', 'username': 'mattdiener'}Message: |