You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some ideas for making our wait loops more efficient.
1- Decay strategy
In at least our own usage, it would be best if we polled with a longer timeout to start and then shortened it over time, as we get closer to an assumed completion of what we're waiting on. This shouldn't be too complex to implement, but we would have to decide how opinionated to be vs allowing user-control over how the poll duration decays over time -- since the best approach entirely depends on workload, I don't think we should be very opinionated.
2- min(timeout-poll, blockingLock.expiry)
When we're waiting on a lock, we know when it expires. If it expires sooner than our timeout-poll, we should only wait that long (maybe +1ms or something). There's no need to wait 5 seconds if we know the lock we're waiting for expires in 120ms.
The text was updated successfully, but these errors were encountered:
Some ideas for making our wait loops more efficient.
1- Decay strategy
In at least our own usage, it would be best if we polled with a longer timeout to start and then shortened it over time, as we get closer to an assumed completion of what we're waiting on. This shouldn't be too complex to implement, but we would have to decide how opinionated to be vs allowing user-control over how the poll duration decays over time -- since the best approach entirely depends on workload, I don't think we should be very opinionated.
2- min(timeout-poll, blockingLock.expiry)
When we're waiting on a lock, we know when it expires. If it expires sooner than our
timeout-poll
, we should only wait that long (maybe +1ms or something). There's no need to wait 5 seconds if we know the lock we're waiting for expires in 120ms.The text was updated successfully, but these errors were encountered: