await for Tuple of task

[Thaina]

For making a shorthand for parallel wait on multiple task. I think we should let await can be use on tuple of tasks too

this below code is sequencial, not parallel

int x = await db.Load<int>("X");
float f = await db.Load<float>("F");
string s = await db.Load<string>("S");

//

var (x,f,s) = (await db.Load<int>("X"),await db.Load<float>("F"),await db.Load<string>("S"));

For making parallel we need to put it in unnecessary variable

// This is parallel
var taskX = db.Load<int>("X");
var taskF = db.Load<float>("F");
var taskS = db.Load<string>("S");

var (x,f,s) = (await taskX,await taskF,await taskS);

So I propose that we should be able to write it like this

var (x,f,s) = await (db.Load<int>("X"),db.Load<float>("F"),db.Load<string>("S"));

If we write tuple syntax has some item being Task<T> in it, it then can put after await and it would be transpiled, extract all task to it's real value, and replace the tuple with the result from task

This would work like WhenAll but being tuple mean it would be able to deconstructed as each types

[CyrusNajmabadi]

Could you not just a customer GetAwaiter for this? I havne't tried to make this compile, but something like:

    public static TaskAwaiter<(T1, T2)> GetAwaiter<T1, T2>(this (Task<T1>, Task<T2>) tasks)
    {
        return Task.WhenAll(tasks.Item1, tasks.Item2).ContinueWith(arr => (tasks.Item1.Result, tasks.Item2.Result)).GetAwaiter();
    }

Then this would just work. Right? Or is there something i'm missing?

--

Note: real example would properly handle edge cases for tasks completing. But the general idea is there.

[ufcpp]

https://github.com/dotnet/corefx/issues/16010

[Thaina]

Thanks

[jnm2]

Importantly, doing this in the language would necessarily couple the language to the BCL method Task.WhenAll. That seems more like a lib concern.

[HaloFour]

While I agree that the very common case is very easily solved via a library, it does make me think that maybe these are situations that the language would be better suited to handling. The reason being that such libraries would be necessarily limited to the number and type of permutations that it could handle. It's easy if you limit it to just Task<T>, but you can await virtually anything, and with ValueTask<T> and async builders that might become more of a reality. That's something that the language could theoretically handle much more easily given that it could handle each element of the tuple based on its shape. I'm not suggesting that the language do this but I'd be interested in more contexts where the tuple container melts away, like with immediate deconstruction and equality.

[CyrusNajmabadi]

I think shapes should solve that @HaloFour. Shapes most accurately reflect what the language is actually doing. i.e. looking for something that matches an actual pattern rather than being an implementation of an interface.

[CyrusNajmabadi]

For example, you could have an SEnumerable shape. Which would define the right shape and relationship between its members and the SEnumerator type it returned. IEnumerable and IEnumerable<T> would then trivially satisfy those shapes. Then, you could write higher level abstractions on SEnumerable and they would automatically work on IEnumerables, but they would also just work on anything the language thought it could foreach.

Note: if/when shapes get done, we should validate this. It would be really good to ensure that all places where the language is implicitly using shapes internally can be expressible in an explicit manner.

[HaloFour]

@CyrusNajmabadi

That's a great point. If there was an SAwaitable shape then you could easily provide library support to await over tuples of arbitrary awaitables.

[jnm2]

@HaloFour The implementation might be less efficient than Task.WhenAll, but SAwaitable is near the top of the reasons I'm excited about shapes.

The naive approach would be to await iteratively in a loop and stash failures, cancellations and results to be assembled at the end. More efficient would be to hook all awaitables with !IsCompleted up to OnComplete with Interlocked.Decrement with the last one setting a task completion source with the combination of results.

[jnm2]

@Thaina See my comment directly above. As @HaloFour stated well,

Task.WhenAll is what joins the results of all of those individual Task instances back into a single Task that can be awaited. Without that you'd have to implement that logic yourself by enumeration all of the awaitables and registering for completion individually and counting down. It's not hard, but it's not trivial bookkeeping.

Task.WhenAll has access to the Task instances' internal ManualResetEventSlim and other synchronization primitives. It turns the entire operation into a very efficient single MRES wait. Whereas if you do this generally, through the SAwaitable interface, you introduce much more synchronization overhead. Not to mention the getting the exception handling correct.

[HaloFour]

@sharwell (from https://github.com/dotnet/corefx/issues/16010#issuecomment-383948077)

If this was a discussion about ValueTuple<Task, Task> and the like, I think it would make more sense. However, since this proposal is inseparable from the tuple syntax in C#, I would encourage revisiting this from the language perspective, similar to how == and != were implemented.

I would expect a tuple of awaitables to be itself awaitable. Since this is pattern-based language feature, I don't see a way to add it as a library without a combinatorial explosion. The standalone library appears to be a fine placeholder in the absence of language support.

Assuming shapes are added to the language do you not feel it would be sufficient to have library support based around SAwaitable and SAwaiter shapes that match the language pattern for awaitables? You'd need a flavor for each arity but I think you'd be able to avoid the combinatorial explosion.

[MgSam]

Adding my 2¢- I don't think "let's wait for shapes" is a good plan for any given feature- given shapes is not scheduled for any specific language version and indeed may never happen.

[HaloFour]

@MgSam

I don't disagree. Shapes could become the next "source generators".

[yaakov-h]

Arent Shapes at least being prototyped? Source Generators don’t even have a solid vision yet.

[orthoxerox]

@MgSam aren't they a 8.0 candidate?

[jnm2]

The conversation moved to awaiting a tuple of awaitables, but the title is outdated and looks like a duplicate of #380.

I'm 100% in support of the idea of language support for awaiting a tuple of Task objects, now that the BCL team decided they didn't want the GetAwaiter extension methods on ValueTuple<Task<>, ...>.

However, as I've had time to reflect on what it would mean to await a tuple of arbitrary awaitables rather than just Task objects, I've come to see it as a bad idea. For example, it would make it natural to write the following code. Where does the continuation execute?

await (
    FooAsync().ConfigureAwait(false), // Continue on the thread pool
    BarAsync().ConfigureAwait(true), // Continue on the current synchronization context
    Task.Yield(), // Continue on the current synchronization context but schedule it at the end of the queue
    process.WhenExited(), // Continue on the thread watching process events
    BazAsync().ContinueOn(someUISynchronizationContext)); // Continue on a non-current synchronization context

// Where am I? 😬

I think it would be a whole lot healthier to require Task objects and make the user explicitly do .AsTask() on anything that's not a task. This requires you to write instance or extension methods for awaitables that don't already have it (ValueTask does). It's impossible to write code that makes no sense like my example above since it would bring to your attention that .ConfigureAwait(...).AsTask() is meaningless. It steers you toward this code, which is the right way to do things:

await (
    FooAsync(),
    BarAsync(),
    process.WhenExited().AsTask()
    BazAsync());
// On same synchronization context

await Task.Yield();

This still leaves the door open to support other awaitables down the road if it's deemed a performance issue to explicitly remind the reader of the semantics by using .AsTask().

[HaloFour]

@jnm2

I think it would be a whole lot healthier to require Task objects and make the user explicitly do .AsTask() on anything that's not a task.

IMO the benefit to this being a language feature disappears if all of the awaitables have to be a Task. At that point you have a specific API that you can work with and you can somewhat easily write extension/helper methods which would delegate to Task.WhenAll and could return an awaitable where you could configure synchronization. Where I see the benefit of language integration would be support for arbitrary awaitables that you can't handle via extension methods/helpers today without shapes.

[jnm2]

If that's the only benefit of language integration, I'm voting against any language integration unless it has a good story for dealing with the code sample above. (I don't consider undefined behavior or 'last-to-complete wins' a good story because the code is confusing to read and my experience is that last-to-complete is the kind of subtlety that only shifts in production.)

I think language integration would be nice for just the Task case because I don't like adding a NuGet package and using directives for something that makes sense out of the box. It would not surprise me if this doesn't matter very much to the LDT, but it is what it is. I don't think we're better off allowing arbitrary awaitables.

[Thaina]

@jnm2 If your sample above was implemented by Task.WhenAll what behavior it will exhibit?

I think it should be the same, only that it would return a tuple instead of array

[svick]

@Thaina Task.WhenAll only works with Tasks, it's not possible to use it with arbitrary awaitables. On the other hand, if this feature was part of C#, the compiler could generate code that awaits each awaitable and proceeds only after all of them have completed.

[jnm2]

Task.WhenAll would be a useful implementation detail for the language capability to await a tuple, so long as all awaitables are Task objects. (It should be just that: an implementation detail.)

If the compiler generates its own awaiting code, it will have to mimic Task.WhenAll in one important way: an exception thrown by one await should not cause other awaits to be skipped. Otherwise, exceptions from other awaits will be impossible to suppress before they trigger the global exception handler, even if the call site wraps everything in a catch-all.

[qrli]

I find I'm doing Task.WhenAll() more and more often, which cause me to prefer this as a language feature. Without such feature, for now, I can simplify the workaround with existing features to be like the following:

// start all async calls
var (taskX, taskF, taskS) = (db.Load<int>("X"), db.Load<float>("F"), db.Load<string>("S"));
// await the tasks to unwrap, yet still preserve the parallelism
var (x,f,s) = (await taskX, await taskF, await taskS);

[jnm2]

@qrli This is a pitfall:

var (x,f,s) = (await taskX, await taskF, await taskS);

If await taskX throws an exception (due to failure or cancellation) and taskF ortaskS also fail, their exceptions are uncatchable by the caller because they are never awaited. They will trigger the global TaskScheduler.UnobservedTaskException on the next GC which is an arbitrary amount of time into the future.

[qrli]

@jnm2 That's a good point.
I just looked up docs, and found that TaskScheduler.UnobservedTaskException no longer terminates process by default since .net 4.5.

So, in practice, it should be similar to await Task.WhenAll(), where only a single exception is popped out. I'm not very sure how the other exceptions are handled internally, but the apparent behavior is OK to me, which means the other exceptions are thrown away. Unless there are some very critical exception which must be handled, but I don't encounter any such scenario.

[Thaina]

@qrli Shouldn't we get AggregatedException normally ?

[jnm2]

@qrli It no longer terminates the process by default, but it's still quite nasty when UnobservedTaskException causes your UI to notify the user that an error has occurred and send logs, even when the error was anticipated by the caller and supposedly handled. ADO.NET had this kind of bug, where it dropped an internal Task object on the floor during certain scenarios and forced us to show error UI for SqlExceptions that the caller should have caught.

async Task Caller(CancellationToken cancellationToken)
{
    try
    {
        await FooAsync(cancellationToken);
    }
    catch (Exception ex) // Just to make the point
    {
        // If more than one tasks in FooAsync ends up having exceptions, the first is in `ex`
        // and the rest are now a ticking time bomb waiting for GC.
    }
}

async Task FooAsync(CancellationToken cancellationToken)
{
    var (taskX, taskF, taskS) = (db.Load<int>("X"), db.Load<float>("F"), db.Load<string>("S"));
    // await the tasks to unwrap, yet still preserve the parallelism
    var (x,f,s) = (await taskX, await taskF, await taskS);
}

I've also seen processes go for minutes before the next GC. A very delayed error UI really confuses users (not to mention programmers) and obscures the actual steps to reproduce the crash.

So: while in limited situations, namely top-level application code that has no caller other than a framework (Program.MainAsync, ASP.NET controller methods (maaaybe), desktop UI event handlers), or unless you know that the user won't be notified and long delays don't matter, it's not really a pattern that should be followed. And if any of that ever changes or the code moves around, there will be nothing to remind you to fix the time-bombing code.

You might be interested in https://www.nuget.org/packages/TaskTupleAwaiter/ which enables safe, WhenAll-backed syntax:

var (policy, preferences) = await (
    GetPolicyAsync(policyId, cancellationToken),
    GetPreferencesAsync(cancellationToken)
).ConfigureAwait(false);

[jnm2]

@Thaina By design, tasks only throw the first exception when awaited. This avoids exception-handling pitfalls in C#. In my experience with async concurrency you aren't losing anything. I'd even say suppressing second and third exceptions is a helpful noise filter. Here's a thread that discusses this topic: buvinghausen/TaskTupleAwaiter#7 (comment)

[qrli]

@Thaina Task gives you AggregatedException, but await unwraps it and gives you the first useful inner exception.

@jnm2 How does Task internally determine whether a task exception is unobserved? I don't feel "unobserved" can be easily defined. And what about @CyrusNajmabadi 's example:

  public static TaskAwaiter<(T1, T2)> GetAwaiter<T1, T2>(this (Task<T1>, Task<T2>) tasks)
    {
        return Task.WhenAll(tasks.Item1, tasks.Item2).ContinueWith(arr => (tasks.Item1.Result, tasks.Item2.Result)).GetAwaiter();
    }

When tasks.Item1.Result throws, will the exception in tasks.Item2 be treated as unobserved?

[jnm2]

@qrli Observing is well-defined as either calling the Task.Exception getter or calling a method that causes the exception to be thrown, such as task.GetAwaiter().GetResult(), the method that the await keyword calls on completion.

Since tasks.Item2.Result throws if there is an exception, the exception will always be observed.

Cyrus' example is a less optimized version of the code in https://www.nuget.org/packages/TaskTupleAwaiter. TaskTupleAwaiter also gives you .ConfigureAwait on tuples of tasks.

[jnm2]

Actually, @CyrusNajmabadi's version has a flaw. It erroneously wraps exceptions with AggregateException when awaited. arr.GetAwaiter().GetResult() should be called before each task's .Result property is accessed.

In general, .Result is only correct to use if task.Status == TaskStatus.RanToCompletion because it will not block or throw a wrapped exception.