Async CTP Refresh - design changes

re: Async CTP Refresh - design changes

Richard — Thu, 05 May 2011 12:35:31 GMT

I think there's a small typo in the first example:

"Dim i = $temp.GetResult()

i = Nothing"

Surely the second line should be "$temp = Nothing"?

re: Async CTP Refresh - design changes

Lucian Wischik, MSFT — Mon, 18 Apr 2011 13:37:50 GMT

Alex, that's a nice idea. But note that "f2" actually will emit a warning ("Warning: this async method lacks awaits. Consider running it on a background thread using await Task.Run, or awaiting the async version of some APIs")... it didn't really seem worth optimizing code that generated a warning!

re: Async CTP Refresh - design changes

Alex Corrado — Mon, 18 Apr 2011 01:40:20 GMT

Lucian, thank you for sharing so many details about the development of the Async CTP. I started my own async method framework before the CTP was first announced, and it has been fascinating to compare your implementation choices with my own. In the example you gave above about the "Costs of async," you had this method:

Async Function f2() As Task(Of Integer)

Return 1

End Function

You seem to indicate that the above would still be transformed into a state machine. Why not instead add an implicit conversion between T and a completed Task<T>? Then, only perform the full transformation when the async method actually awaits something. You could save 2 of the extra heap allocs you mentioned.

re: Async CTP Refresh - design changes

tobi — Sat, 16 Apr 2011 10:22:06 GMT

You are right with handlers but what if you wanted to kick of an async "workflow" by starting a void-returning method. An example would be AnimateElement(UIElement e). If the element e was null, I would prefer the exception being thrown right after the call happened so I could track down where the null ref came from. Maybe exceptions could be thrown directly up to the first async-point (because that code will execute sequentially anyway).

re: Async CTP Refresh - design changes

Lucian Wischik, MSFT — Fri, 15 Apr 2011 21:10:16 GMT

Tobi - for "Argument Validation", let's look at how a regular event-handler vs an async event handler will work...

Sub Button1_Click() Handles Button1.Click

If String.IsNullOrEmpty(TextBox1.Text) Then Throw New Exception("Please supply TextBox1")

...

End Sub

Async Sub Button1_Click() Handles Button1.Click

Await TaskEx.Yield()

If String.IsNullOrEmpty(TextBox1.Text) Then Throw New Exception("Please supply TextBox1")

End Sub

In both cases, it's the winforms message-loop that dispatched the Button1Click.

In the first case, the exception gets sent to the caller, which in this case is the winforms message-loop.

In the second case, the exception gets posted to the current synchronization context, which in this case is the winforms message loop.

So in both cases they end up on the winforms message-loop, and the UI experience is the same.

As for the debugging experience? We're still fine-tuning this. But an exception thrown from an async sub will almost certainly count as "unhandled by user code", giving VS the opportunity to stop right there at the moment it's thrown.

re: Async CTP Refresh - design changes

tobi — Fri, 15 Apr 2011 20:07:01 GMT

What does the change mean to argument validation? I think it means that those exceptions will not appear directly at the call site but at some other random place, like on the message loop in WinForms. Isn't that hard to diagnose?