Comments 9
Хотелось бы всё же увидеть в статье главный вопрос автора - к чему же может привести непонимание мидлами наличия аллокаций в асинхронном коде? Просто сейчас статья толковая, подробностей много, а что автор победил - не сказано.
Я так понял, что сам факт наличия аллокаций.
Ну т.е. бывают иногда прокси методы, которые выглядят типа:
public async Task<T> Do()
{
await impl.Do();
}
И вот их можно переписать как
public Task<T> Do()
{
return impl.Do();
}
Убрав аллокацию =)
Так не получается, даже две строки:
await Task.Delay(delay);
_fileContent = await File.ReadAllTextAsync("file1");
чистой оберткой не являются.
Придется подождать ответа автора...
Да, именно поэтому и еще по ряду причин David Fowler в своем AsyncGuidance не рекомендует делать такие прокси. Поэтому, ответ использовать их или нет
зависит от того, что важнее - корректный стек вызовов плюс другие плюшки, либо мизерный выигрыш от экономии аллокации в куче.
Я думаю в коде машины состояний после рефакторинга перед catch пропущено DelayAwaiter.GetResult();что важно для правильного завершения работы метода
Builder.AwaitUnsafeOnCompleted(ref DelayAwaiter, ref this);
break;
}
DelayAwaiter.GetResult();
}
catch (Exception exception)
{
CurrentState = State.Finished;
Builder.SetException(exception);
}
В Бонусе: похоже на то что при переходе по ко второму состоянию в свиче он попробует залочить obj ещё раз и тут будет висеть (нечно похожее на deadlock) поэтому и запрещено)
Еще раз про асинхронную машину состояний и где именно там аллокации