async-workflow

Unexpected behavior with exception handling in async, possible bug?

由 前提是你 提交于 2019-12-12 16:19:17
问题 I have stumbled upon a problem when calling a nested Async which happens to be null. An exception is raised but it can't be catched with any of the normal exception handling methods Async workflows provide. The following is a simple test which reproduces the problem: [<Test>] let ``Nested async is null with try-with``() = let g(): Async<unit> = Unchecked.defaultof<Async<unit>> let f = async { try do! g() with e -> printf "%A" e } f |> Async.RunSynchronously |> ignore which results in the

Why do I have to wrap an Async<T> into another async workflow and let! it?

由 拜拜、爱过 提交于 2019-12-10 13:58:35
问题 I'm trying to understand async workflows in F# but I found one part that I really don't understand. The following code works fine: let asynWorkflow = async{ let! result = Stream.TryOpenAsync(partition) |> Async.AwaitTask return result } let stream = Async.RunSynchronously asynWorkflow |> fun openResult -> if openResult.Found then openResult.Stream else Stream(partition) I define a async workflow where TryOpenAsync returns a Task<StreamOpenResult> type. I convert it to Async<StreamOpenResult>

F# Async.RunSynchronously with timeout and cancellationToken

由 社会主义新天地 提交于 2019-12-09 18:32:03
问题 When calling Async.RunSynchronously with a timeout and a CancellationToken, the timeout value seems to be ignored. I can work around this by calling CancelAfter on the CancellationToken, but ideally I'd like to be able to distinguish between exceptions that occur in the workflow, TimeOutExceptions and OperationCanceledExceptions. I believe the sample code below demonstrates this. open System open System.Threading let work = async { let endTime = DateTime.UtcNow.AddMilliseconds(100.0) while

Best practices to parallelize using async workflow

由 半城伤御伤魂 提交于 2019-12-09 16:08:24
问题 Lets say I wanted to scrape a webpage, and extract some data. I'd most likely write something like this: let getAllHyperlinks(url:string) = async { let req = WebRequest.Create(url) let! rsp = req.GetResponseAsync() use stream = rsp.GetResponseStream() // depends on rsp use reader = new System.IO.StreamReader(stream) // depends on stream let! data = reader.AsyncReadToEnd() // depends on reader return extractAllUrls(data) } // depends on data The let! tells F# to execute the code in another

Best practices to parallelize using async workflow

由 跟風遠走 提交于 2019-12-04 04:24:45
Lets say I wanted to scrape a webpage, and extract some data. I'd most likely write something like this: let getAllHyperlinks(url:string) = async { let req = WebRequest.Create(url) let! rsp = req.GetResponseAsync() use stream = rsp.GetResponseStream() // depends on rsp use reader = new System.IO.StreamReader(stream) // depends on stream let! data = reader.AsyncReadToEnd() // depends on reader return extractAllUrls(data) } // depends on data The let! tells F# to execute the code in another thread, then bind the result to a variable, and continue processing. The sample above uses two let

Async.Catch doesnt work on OperationCanceledExceptions

由 我的梦境 提交于 2019-11-30 20:54:52
I use Async.Catch to handle exceptions thrown by async workflows: work |> Async.Catch |> Async.RunSynchronously |> fun x -> match x with | Choice1Of2 _ -> () // success | Choice2Of2 ex -> // failure, handle exception Today I noticed that OperationCanceledExceptions aren't handled by Async.Catch. Instead of getting a Choice from Async.Catch the exception keeps bubbling up until it hits me. I expected the following test to be red, but it's green: [<Test>] let ``Async.Catch doesnt work on OperationCancelledExceptions``() = use cancellationTokenSource = new System.Threading.CancellationTokenSource

What is the Scala equivalent of F#'s async workflows?

由 心不动则不痛 提交于 2019-11-30 14:42:02
问题 What is the Scala equivalent of F#'s async workflows? For example, how would following F# snippet translate to idiomatic Scala? open System.Net open Microsoft.FSharp.Control.WebExtensions let urlList = [ "Microsoft.com", "http://www.microsoft.com/" "MSDN", "http://msdn.microsoft.com/" "Bing", "http://www.bing.com" ] let fetchAsync(name, url:string) = async { try let uri = new System.Uri(url) let webClient = new WebClient() let! html = webClient.AsyncDownloadString(uri) printfn "Read %d

What is the Scala equivalent of F#'s async workflows?

由 血红的双手。 提交于 2019-11-30 11:22:47
What is the Scala equivalent of F#'s async workflows? For example, how would following F# snippet translate to idiomatic Scala? open System.Net open Microsoft.FSharp.Control.WebExtensions let urlList = [ "Microsoft.com", "http://www.microsoft.com/" "MSDN", "http://msdn.microsoft.com/" "Bing", "http://www.bing.com" ] let fetchAsync(name, url:string) = async { try let uri = new System.Uri(url) let webClient = new WebClient() let! html = webClient.AsyncDownloadString(uri) printfn "Read %d characters for %s" html.Length name with | ex -> printfn "%s" (ex.Message); } let runAll() = urlList |> Seq

Async.Catch doesnt work on OperationCanceledExceptions

由 别来无恙 提交于 2019-11-30 05:02:45
问题 I use Async.Catch to handle exceptions thrown by async workflows: work |> Async.Catch |> Async.RunSynchronously |> fun x -> match x with | Choice1Of2 _ -> () // success | Choice2Of2 ex -> // failure, handle exception Today I noticed that OperationCanceledExceptions aren't handled by Async.Catch. Instead of getting a Choice from Async.Catch the exception keeps bubbling up until it hits me. I expected the following test to be red, but it's green: [<Test>] let ``Async.Catch doesnt work on

Is there an async version of DirectoryInfo.GetFiles / Directory.GetDirectories in dotNet?

由 那年仲夏 提交于 2019-11-28 05:44:34
Is there an asynchronous version of DirectoryInfo.GetFiles / Directory.GetDirectories in dotNet? I'd like to use them in an F# async block, and it'd be nice to have a version that can be called with AsyncCallbacks. Problem is I'm trying to suck in a bunch of directories, probably on SMB mounts over slow network connections, and I don't want a bunch of thread pool threads sitting around waiting for network reads when they could be doing other work. No, I don't think there is. The pool thread approach is probably the most pragmatic. Alternatively, I guess you could drop down to P/Invoke - but
订阅 async-workflow