почему .net Framework не выполняет асинхронную работу автоматически - PullRequest
Новая
       9

почему .net Framework не выполняет асинхронную работу автоматически

0 голосов
/ 06 ноября 2019

Может быть, я упускаю что-то очевидное здесь. Таким образом, в C # есть функции асинхронности / ожидания, которые мы используем в операциях ввода-вывода, чтобы освободить поток во время ожидания завершения ввода-вывода.

Вопрос в том, почему мы должны это делать, а фреймворк не можетсделать это автоматически?

РЕДАКТИРОВАТЬ Чтобы быть кратким, что было бы круто, мы называем 

var a = File.ReadAllText

, и это работает точно так же, как если бы мы назвали 

var a = await File.ReadAllTextAsync

потому что .net Framework будет отвечать за асинхронный вызов всех операций ввода-вывода (которые он получает из кода пользователя в виде синхронного кода).

1 Ответ

2 голосов
/ 06 ноября 2019

Если бы эти две строки были эквивалентны: 

string s = await File.ReadAllTextAsync(); // Current syntax

string s = File.ReadAllText(); // Proposed syntax

... тогда мы больше не смогли бы создать Task, не ожидая его немедленно. Таким образом, мы не могли сделать все эти классные кадры с Task.WhenAll, Task.WhenAny и т. Д., Которые допускают параллелизм. Затем нам потребуется другое ключевое слово для обозначения не ожидающего, например: 

var s = defer File.ReadAllText(); // s is Task<string>

Или выведите его по типу возвращаемой переменной: 

Task<string> s = File.ReadAllText(); // defer is inferred

Любой метод, содержащий строкуstring s = File.ReadAllText(); теперь будет неявно асинхронным, поэтому он должен вернуть Task. Для обеспечения согласованности и упрощения работы разработчиков, вероятно, следует разрешить сохранять развернутые типы в сигнатуре. Пример эквивалентного текущего и предлагаемого синтаксиса: 

public async Task<string> GetData() => await File.ReadAllTextAsync(); // Current syntax

public string GetData() => File.ReadAllText(); // Proposed syntax

Я не уверен, насколько далеко вы можете пойти в этом эксперименте. Я предполагаю, что если бы async / await было введено вместе с библиотекой TPL, вы могли бы пройти несколько миль, прежде чем столкнуться с препятствием. Но так как TPL (2010) предшествовал async / await (2012), уже было много API, выставляющих тип Task, и множество кода, использующего эти API, уже сломанного с новым синтаксисом.

...