Async czeka w linq select

Muszę zmodyfikować istniejący program i zawiera następujący kod:

var inputs = events.Select(async ev => await ProcessEventAsync(ev))
                   .Select(t => t.Result)
                   .Where(i => i != null)
                   .ToList();

Ale wydaje mi się to bardzo dziwne, przede wszystkim użycie asynci awaitw selekcji. Zgodnie z tą odpowiedzią Stephena Cleary'ego powinienem móc je odrzucić.

Następnie drugi, Selectktóry wybiera wynik. Czy nie oznacza to, że zadanie nie jest w ogóle asynchroniczne i jest wykonywane synchronicznie (tyle wysiłku na nic), czy też będzie wykonywane asynchronicznie, a po zakończeniu reszta zapytania zostanie wykonana?

Czy powinienem napisać powyższy kod jak poniżej według innej odpowiedzi Stephena Cleary :

var tasks = await Task.WhenAll(events.Select(ev => ProcessEventAsync(ev)));
var inputs = tasks.Where(result => result != null).ToList();

i czy jest zupełnie tak samo?

var inputs = (await Task.WhenAll(events.Select(ev => ProcessEventAsync(ev))))
                                       .Where(result => result != null).ToList();

Kiedy pracuję nad tym projektem, chciałbym zmienić pierwszy przykład kodu, ale nie jestem zbyt chętny do zmiany (najwyraźniej działającego) kodu asynchronicznego. Może po prostu martwię się o nic, a wszystkie 3 próbki kodu robią dokładnie to samo?

ProcessEventsAsync wygląda następująco:

async Task<InputResult> ProcessEventAsync(InputEvent ev) {...}

var inputs = events.Select(async ev => await ProcessEventAsync(ev))
                   .Select(t => t.Result)
                   .Where(i => i != null)
                   .ToList();

Ale wydaje mi się to bardzo dziwne, przede wszystkim użycie async i czekanie w selekcji. Zgodnie z tą odpowiedzią Stephena Cleary'ego powinienem móc je odrzucić.

Wezwanie do Selectjest ważne. Te dwie linie są zasadniczo identyczne:

events.Select(async ev => await ProcessEventAsync(ev))
events.Select(ev => ProcessEventAsync(ev))

(Istnieje niewielka różnica w sposobie wyrzucenia wyjątku synchronicznego ProcessEventAsync, ale w kontekście tego kodu nie ma to żadnego znaczenia).

Następnie drugi Wybierz, który wybiera wynik. Czy to nie oznacza, że ​​zadanie nie jest w ogóle asynchroniczne i jest wykonywane synchronicznie (tyle wysiłku na nic), czy też będzie wykonywane asynchronicznie, a po zakończeniu reszta zapytania zostanie wykonana?

Oznacza to, że zapytanie jest blokowane. Więc to nie jest tak naprawdę asynchroniczne.

Rozbijając to:

var inputs = events.Select(async ev => await ProcessEventAsync(ev))

najpierw rozpocznie operację asynchroniczną dla każdego zdarzenia. Następnie ta linia:

                   .Select(t => t.Result)

będzie czekać, aż te operacje zakończą się pojedynczo (najpierw czeka na operację pierwszego zdarzenia, potem następne, potem następne itd.).

To jest część, na której mi nie zależy, ponieważ blokuje, a także zawija wszelkie wyjątki AggregateException.

i czy jest zupełnie tak samo?

var tasks = await Task.WhenAll(events.Select(ev => ProcessEventAsync(ev)));
var inputs = tasks.Where(result => result != null).ToList();

var inputs = (await Task.WhenAll(events.Select(ev => ProcessEventAsync(ev))))
                                       .Where(result => result != null).ToList();

Tak, te dwa przykłady są równoważne. Obaj rozpoczynają wszystkie operacje asynchroniczne ( events.Select(...)), następnie asynchronicznie czekają na zakończenie wszystkich operacji w dowolnej kolejności ( await Task.WhenAll(...)), a następnie wykonują resztę pracy ( Where...).

Oba te przykłady różnią się od oryginalnego kodu. Oryginalny kod jest blokujący i zawija wyjątki AggregateException.

Istniejący kod działa, ale blokuje wątek.

.Select(async ev => await ProcessEventAsync(ev))

tworzy nowe zadanie dla każdego wydarzenia, ale

.Select(t => t.Result)

blokuje wątek czekając na zakończenie każdego nowego zadania.

Z drugiej strony twój kod daje ten sam wynik, ale zachowuje asynchroniczność.

Tylko jeden komentarz do Twojego pierwszego kodu. Ta linia

var tasks = await Task.WhenAll(events...

utworzy jedno zadanie, więc zmienna powinna być nazwana w liczbie pojedynczej.

Wreszcie twój ostatni kod robi to samo, ale jest bardziej zwięzły

Dla odniesienia: Task.Wait / Task.WhenAll

Przy obecnych metodach dostępnych w Linq wygląda to dość brzydko:

var tasks = items.Select(
    async item => new
    {
        Item = item,
        IsValid = await IsValid(item)
    });
var tuples = await Task.WhenAll(tasks);
var validItems = tuples
    .Where(p => p.IsValid)
    .Select(p => p.Item)
    .ToList();

Miejmy nadzieję, że kolejne wersje .NET dostarczą bardziej eleganckiego narzędzia do obsługi zbiorów zadań i zadań związanych z kolekcjami.

Użyłem tego kodu:

public static async Task<IEnumerable<TResult>> SelectAsync<TSource,TResult>(this IEnumerable<TSource> source, Func<TSource, Task<TResult>> method)
{
      return await Task.WhenAll(source.Select(async s => await method(s)));
}

lubię to:

var result = await sourceEnumerable.SelectAsync(async s=>await someFunction(s,other params));

Wolę to jako metodę rozszerzenia:

public static async Task<IEnumerable<T>> WhenAll<T>(this IEnumerable<Task<T>> tasks)
{
    return await Task.WhenAll(tasks);
}

Aby można go było używać z łańcuchem metod:

var inputs = await events
  .Select(async ev => await ProcessEventAsync(ev))
  .WhenAll()