New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Async.withCancellation #685

Open
TheAngryByrd opened this Issue Aug 17, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@TheAngryByrd

TheAngryByrd commented Aug 17, 2018

Add Async.withCancellation

I propose we add Async.withCancellation. This would allow using outside CancellationToken, such as the RequestAborted from HttpContext. The problem with Async.Start is it does not provide a way to return a value.

The existing way of approaching this problem in F# is provided here:

https://gist.github.com/eulerfx/c41d50c6fba8e88cf16a21ed7c3c14bd#file-async-withcancellation-fs

Inlined:

let withCancellation (ct:CancellationToken) (a:Async<'a>) : Async<'a> = async {
  let! ct2 = Async.CancellationToken
  use cts = CancellationTokenSource.CreateLinkedTokenSource (ct, ct2)
  let tcs = new TaskCompletionSource<'a>()
  use _reg = cts.Token.Register (fun () -> tcs.TrySetCanceled() |> ignore)
  let a = async {
    try
      let! a = a
      tcs.TrySetResult a |> ignore
    with ex ->
      tcs.TrySetException ex |> ignore }
  Async.Start (a, cts.Token)
  return! tcs.Task |> Async.AwaitTask }

Pros and Cons

The advantages of making this adjustment to F# are

  • This would be easily discoverable to more user
  • Potentially implemented in a cleaner way

The disadvantages of making this adjustment to F# are

  • None I know of

Extra information

Estimated cost (XS, S, M, L, XL, XXL): XS

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I or my company would be willing to help implement and/or test this
@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Sep 10, 2018

Member

I like this, though the name would have to be PascalCase since it would likely be a static member on the Async type as per the current implementation. An unrelated issue might be moving those into a module, but they would also have to be similarly cased, otherwise we'd break everyone on an upgrade.

Would you like to write an RFC for this?

Member

cartermp commented Sep 10, 2018

I like this, though the name would have to be PascalCase since it would likely be a static member on the Async type as per the current implementation. An unrelated issue might be moving those into a module, but they would also have to be similarly cased, otherwise we'd break everyone on an upgrade.

Would you like to write an RFC for this?

@TheAngryByrd

This comment has been minimized.

Show comment
Hide comment
@TheAngryByrd

TheAngryByrd Sep 10, 2018

Sure! I'll get to this tonight.

TheAngryByrd commented Sep 10, 2018

Sure! I'll get to this tonight.

@TheAngryByrd

This comment has been minimized.

Show comment
Hide comment
@TheAngryByrd

TheAngryByrd Sep 10, 2018

@cartermp is it ok if this still isn't marked as approved in principal?

TheAngryByrd commented Sep 10, 2018

@cartermp is it ok if this still isn't marked as approved in principal?

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Sep 10, 2018

Member

This is ultimately @dsyme's decision, but I'd certainly welcome the addition. If the RFC isn't much work to write, then it probably wouldn't hurt to send the PR.

Member

cartermp commented Sep 10, 2018

This is ultimately @dsyme's decision, but I'd certainly welcome the addition. If the RFC isn't much work to write, then it probably wouldn't hurt to send the PR.

@TheAngryByrd

This comment has been minimized.

Show comment
Hide comment
@TheAngryByrd

TheAngryByrd Sep 10, 2018

Ok sending in a few

TheAngryByrd commented Sep 10, 2018

Ok sending in a few

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment