Details
-
Improvement
-
Resolution: Unresolved
-
Major - P3
-
None
-
None
-
Service Arch
Description
pauseWhileSet doesn't meet user needs, so a client added pauseWhileSetAndNotCancelled, so it can wait polling on either an Interruptible or a CancelationToken or on the FailPoint shouldFail becoming false.
Clearly we can't extend FailPoint every time a client comes up with a new way to stop waiting for something. It's also annoying that the granularity isn't tunable by the caller.
The real central value-add of .pauseWhileSet was always that it can check on the FailPoint repeatedly while having its multiple hits count as just one hit in the `nTimes` accounting. This can be abstracted out more gracefully, and we can let the clients provide their own implementations for how to sleep, how to poll, and when to break the loop.