Здравствуйте, Serginio1, Вы писали:

S>>>Вместо awaite File.ReadAllTextAsync нужно создавать бэкграунд поток, передавать в него метод в котором вызывать в итоге File.ReadAllText
_>>Потому что для однопользовательского случая такая задача масштабируется гораздо лучше.
S> И чем это лучше? Ты запускаешь отдельный поток. Который нихрена не делает, только ожидает когда данные считаются.

И в чём проблема с этим? ) Речь же не про тысячу таких потоков, а про один. )

S>При этом морозит вспомогательный поток через объекты синхронизации до получения данных.

С чего бы это?

S> При awaite File.ReadAllTextAsync данные передаются сразу в главный поток или если использовать .ConfigureAwaite(false) в любой поток.
S> Чем это маштабируется то лучше?

Потому что помимо просто чтения файла в реальном мире у тебя будет ещё и какая-то его минимальная обработка. Например его парсинг. Если использовать твою схему с awaite File.ReadAllTextAsync, где по твоему будет происходить обработка? Если изначальный вызов был у тебя в UI потоке, то и обработка пойдёт там же. И это даже будет нормально работать у тебя на небольших файликах. А потом пользователь загрузит туда гигабайтный файл и всё твоё приложение зависнет на неопределённое время. А для варианта с отдельным потоком, никаких проблем не будет — просто подольше будет идти обработка, но без всяких зависаний приложения.

Ты сейчас наверное скажешь, что правильный программист сразу же выделит парсинг в отдельный поток, как потенциально длительную операцию. Вот только тогда сразу появляется простейший вопрос: а зачем нам тогда нужен асинхронный ввод-вывод, если у нас и так создаётся поток под эту задачу?