C # 5 async CTP: dlaczego wewnętrzny "state" jest ustawiony na 0 w generowanym kodzie przed wywołaniem EndAwait?

W końcu mam prawdziwą odpowiedź. Jakoś to sobie wymyśliłem, ale dopiero po tym, jak Lucian Wischik z zespołu VB potwierdził, że naprawdę jest ku temu dobry powód. Wielkie dzięki dla niego-i proszę odwiedzić jego blog , który rządzi.

Wartość 0 jest tutaj wyjątkowa, ponieważ jest , a nie poprawnym stanem, w którym możesz być tuż przed await w normalnym przypadku. W szczególności nie jest to stan, dla którego maszyna stanowa może skończyć testowanie gdzie indziej. Uważam, że użycie dowolnej nie dodatniej wartości byłoby równie dobre: -1 nie jest używane do tego, ponieważ jest logicznie niepoprawne, ponieważ -1 zwykle oznacza "ukończone". Mógłbym argumentować, że nadajemy dodatkowy sens stanowi 0 w tej chwili, ale ostatecznie to nie ma znaczenia. Celem tego pytania było ustalenie, dlaczego państwo jest w ogóle ustanawiane.

Wartość ma znaczenie, jeśli oczekiwanie kończy się wyjątkiem, który jest przechwytywany. Możemy wrócić do tego samego oczekuj ponownie, ale nie możemy być w stanie oznaczającym "właśnie wracam z tego oczekiwania", ponieważ w przeciwnym razie wszystkie rodzaje kodu zostałyby pominięte. Najłatwiej jest to pokazać na przykładzie. Zauważ, że używam teraz drugiego CTP, więc wygenerowany kod jest nieco inny niż w pytaniu.

Oto metoda asynchroniczna:

static async Task<int> FooAsync()
{
    var t = new SimpleAwaitable();

    for (int i = 0; i < 3; i++)
    {
        try
        {
            Console.WriteLine("In Try");
            return await t;
        }                
        catch (Exception)
        {
            Console.WriteLine("Trying again...");
        }
    }
    return 0;
}

Koncepcyjnie SimpleAwaitable może być dowolne - może zadanie, może coś innego. Na potrzeby moich testów, to zawsze zwraca false dla IsCompleted i rzuca wyjątek w GetResult.

Oto wygenerowany kod dla MoveNext:

public void MoveNext()
{
    int returnValue;
    try
    {
        int num3 = state;
        if (num3 == 1)
        {
            goto Label_ContinuationPoint;
        }
        if (state == -1)
        {
            return;
        }
        t = new SimpleAwaitable();
        i = 0;
      Label_ContinuationPoint:
        while (i < 3)
        {
            // Label_ContinuationPoint: should be here
            try
            {
                num3 = state;
                if (num3 != 1)
                {
                    Console.WriteLine("In Try");
                    awaiter = t.GetAwaiter();
                    if (!awaiter.IsCompleted)
                    {
                        state = 1;
                        awaiter.OnCompleted(MoveNextDelegate);
                        return;
                    }
                }
                else
                {
                    state = 0;
                }
                int result = awaiter.GetResult();
                awaiter = null;
                returnValue = result;
                goto Label_ReturnStatement;
            }
            catch (Exception)
            {
                Console.WriteLine("Trying again...");
            }
            i++;
        }
        returnValue = 0;
    }
    catch (Exception exception)
    {
        state = -1;
        Builder.SetException(exception);
        return;
    }
  Label_ReturnStatement:
    state = -1;
    Builder.SetResult(returnValue);
}

Musiałem przesunąć Label_ContinuationPoint, aby nadać mu poprawny kod - w przeciwnym razie nie wchodzi on w zakres goto instrukcji-ale to nie ma wpływu na odpowiedź.

Pomyśl o tym, co się stanie, gdy GetResult rzuci swój wyjątek. Przejdziemy przez blok catch, increment i, a następnie ponownie pętlę (zakładając, że i jest nadal mniejsza niż 3). Wciąż jesteśmy w stanie były przed telefonem... ale kiedy wejdziemy do bloku try, musimy wydrukować "in Try" i ponownie wywołaćGetAwaiter... i zrobimy to tylko wtedy, gdy stan nie będzie 1. Bez przypisania state = 0, użyje istniejącego awaitera i pominie wywołanie Console.WriteLine.

To dość kręta część kodu do pracy, ale to tylko pokazuje rodzaje rzeczy, o których zespół musi myśleć. Cieszę się, że nie jestem odpowiedzialny za wdrożenie tego:)