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
If the delay is zero or negative, instead of running a timer we should immediately check if the promise is resolved, and if not then time it out. This avoids an unnecessary timer and possibly operation queue work.
Implementation note: We should hop on the context, then run the timeout block there. Don't check it synchronously. The timeout block already does what we want and verifies that the promise hasn't resolved yet.
Design note: The above is different than checking result immediately and timing out if not. In particular, if we're using a context other than immediate, if the promise's upstream has resolved and the propagation is pending on that context, it may resolve the given promise prior to the timeout block firing. This matches current behavior. We should document that if the user wants to do the equivalent of if promise.result == nil { timeout() } then they can pass the .immediate context, or the nowOr(_) context (see #34).
The text was updated successfully, but these errors were encountered:
It occurs to me that this will change the behavior of timeout(on: .immediate, delay: 0). With the old behavior that would timeout on the same queue as .auto, thus giving the promise a chance to resolve first, but with the new behavior it wouldn't. This is not documented behavior though.
Example:
DispatchQueue.main.async{letpromise=Promise<Int,String>(on:.main,{(resolver)in
resolver.fulfill(with:42)}).timeout(on:.immediate, delay:0)// old behavior will fulfill asynchronously on the main queue// new behavior will reject synchronously with a timeout error}
If the delay is zero or negative, instead of running a timer we should immediately check if the promise is resolved, and if not then time it out. This avoids an unnecessary timer and possibly operation queue work.
Implementation note: We should hop on the context, then run the timeout block there. Don't check it synchronously. The timeout block already does what we want and verifies that the promise hasn't resolved yet.
Design note: The above is different than checking
result
immediately and timing out if not. In particular, if we're using a context other thanimmediate
, if the promise's upstream has resolved and the propagation is pending on that context, it may resolve the given promise prior to the timeout block firing. This matches current behavior. We should document that if the user wants to do the equivalent ofif promise.result == nil { timeout() }
then they can pass the.immediate
context, or thenowOr(_)
context (see #34).The text was updated successfully, but these errors were encountered: