await anything;

re: await anything;

Stephen Toub - MSFT — Thu, 23 Feb 2012 03:06:14 GMT

Hi Ido-

I'm glad you like the post, and thanks for the feedback. To be clear, neither of those control or culture examples actually ship in the Framework, and I was simply showing the kinds of things that are possible with the pattern. Whether you choose to do this in your own code is entirely up to you :)

re: await anything;

It's that abuse? — Wed, 22 Feb 2012 22:11:36 GMT

Hi,

This post is very interesting and show the power of using a pattern instead of concrete types.

The thing that bugs me is that the last two ideas of await button and await culture seem like an abuse to me.

I can read and understand what await DownloadAsync means but reading await button is not logical to me. I can see why it working but in order to understand that you have to know the internal implementation of both Awaiter pattern and SynchornizationContext, both of which should be hidden if used correctly.

As a comparison - I can add operator ++ to Thread which change it's priority but it will just abuse operator overloading.

That's only my opinion :)

Thanks for the great work of finally bring great async pattern that works even on UI code.

Ido

re: await anything;

Alex Petersen — Wed, 02 Mar 2011 13:01:46 GMT

This is awesome stuff. I can already imagine how easy it would be to write coroutines using async/await.

re: await anything;

Stephen Toub - MSFT — Sun, 16 Jan 2011 19:49:53 GMT

Hi yzorg-

Thanks for the feedback and suggestion. It is likely that you'll need to wait for a beta release in order to get such documentation, but we'll see if there's something we can do in the meantime (e.g. putting together a CHM file that documents the new members).

re: await anything;

yzorg — Fri, 14 Jan 2011 19:05:00 GMT

I love what I'm seeing, but I'm a practitioner and not an early adopter. I think you'd get more adoption from practitioners if documentation for TaskEx was up on MSDN library somewhere. (I think I'd use it in my personal PowerShell and data migration code, of course not production uses). Any ETA on when there will be basic docs on MSDN for the new CTP types like TaskEx? Would we have to wait for a .NET 5 beta?

re: await anything;

tobi — Fri, 14 Jan 2011 16:05:52 GMT

I would add another con: There is a perfectly valid workaround to not having an interface and achieving basically the same thing: Task.

re: await anything;

Lucian Wischik, MSFT — Fri, 14 Jan 2011 15:52:27 GMT

Paul, we spent a long time evaluating IAwaitable before deciding against it. Here are some of the factors.

(1. PRO) If would be good for "Await" to be like "For Each". For Each first looks to see if its argument satisfies the enumerable pattern. If not, it looks for an interface IEnumerable<T> / IEnumerable and uses that. It would be clean if Await did the same thing.

(2. CON) At the moment we have a large set of Task-related combinators, e.g. Task.WaitAll and Task.WaitAny, that operate upon tasks. To make IAwaitable usable, we'd have to add extra overloads of them take IAwaitable as well.

(3. -) Actually, not all awaitables are peers. We wouldn't want "Task.WhenAll(Task.Run(...), Task.Yield())" to typecheck. It doesn't make sense. We kind of like that the type system keeps them apart. (Of course it still could even with IAwaitable, in the same way that you can For Each over things that aren't IEnumerable).

(4. CON) Users would have to decide all the time whether their API surface area should deal in Tasks or IAwaitables -- a decision that most would have to make without it actually benefitting them.

(5. CON) We'd have to decide async methods should have return type Task or IAwaitable or both. If Task, then it adds to user confusion about whether their signatures should have Task or IAwaitable. If IAwaitable, then it cuts users off from all the existing Task-based APIs. If both, then it adds to user confusion about what their async method should return.

(6. PRO) If we created an IEnumerable, then users could write their own libraries of combinators that operate over anyone's awaitable stuff.

(7. CON) At this stage, we have only one and a half good examples of things that are awaitable -- namely, Task and maybe IObservable. It'd be a mistake to create a fundamental framework type like IAwaitable with so few uses of it.

(8. CON) IAwaitable feels a bit like IObservable.

I think it was 5+7 that were the biggest factors in our decision.

Lucian Wischik, VB language PM

re: await anything;

Stephen Toub - MSFT — Fri, 14 Jan 2011 15:35:23 GMT

Tridex, glad you like it! Enjoy your weekend :)

re: await anything;

Stephen Toub - MSFT — Fri, 14 Jan 2011 15:34:54 GMT

tobi, oops, in my haste I wrote Set instead of TrySet. Fixed above.

re: await anything;

tobi — Fri, 14 Jan 2011 13:39:11 GMT

There is a race condition here:

process.Exited += (s, e) => tcs.SetResult(process.ExitCode);

if (process.HasExited) tcs.SetResult(process.ExitCode);

It might detect exit twice.