Avatar
# This library is only hypothetical, sorry from cancel_tokens import cancel_after, cancel_on_callback # Returns an opaque CancelToken object that enters the "cancelled" # state after 10 seconds. cancel_token = cancel_after(10) # So this request gives up after 10 seconds requests.get("https://...", cancel_token=cancel_token) # Returns an opaque CancelToken object that enters the "cancelled" # state when the given callback is called. cancel_callback, cancel_token = cancel_on_callback() # Arrange for the callback to be called if someone clicks "stop" stop_button.on_press = cancel_callback # So this request gives up if someone clicks 'stop' requests.get("https://...", cancel_token=cancel_token) https://vorpus.org/blog/timeouts-and-cancellation-for-humans/ (edited)
4:33 AM
Joe Groff が挙げてる方式。(斜め読みでコード抜き出しただけなので本当にこれが言いたいのかわからないけど。) (edited)
4:34 AM
トークンとコールバックが別で扱われてるのがちょっと気持ち悪い気がする。
4:40 AM
↓みたいな方がいい気がする。 struct Canceller { func cancel() func onCancel(_ body: () -> Void) } func download(from url: URL, canceller: Canceller? = nil) async throws -> Data let canceller = Canceller() let data = try await download(from: url, canceller: canceller) DispatchQueue.main.asyncAfter(deadline: .now() + 10.0) { canceller.cancel() } stopButton.onTap { canceller.cancel() }
4:41 AM
よくみたら @omochimetaru 案とほぼ同じ気がする・・・。
4:41 AM
ちがうか。
4:44 AM
↑の Canceller だと context と token の役割が一体化していて、 canceller に onCancel ができるのがまずいのか。
4:49 AM
外部に公開するときに純粋に cancel の機能だけを公開したい。
4:50 AM
でも外部から Canceller を注入するなら、一体化しててまずいことってあるかな?