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


S>>·>_Зачем_ он асинхронный?
S>> Затем что задача выполняется в отдельном потоке.
·>Выполнение в отдельном потоке означает параллельное выполнение. Это не отвечает на вопрос _зачем_ метод обязан быть асинхронным.

Задача может выполняться как в отдельном потоке LongRunning, так и пуле потоков. А там можно настроить, что бы пул потока состоял из одного потока.
Кроме того операции ввода вывода используют один поток использую один поток для контроля выполнения через контроллер.

S>>·>Ок, уже лучше. А _зачем_ нужен асинхронный ввод-вывод? Что плохого в коде, который делает просто что-то вроде print(file.read(...)) или sendResults(sqlQuery.execute(...))?
S>> Да ничего.
·>Именно. Так зачем переписывать "старый код"? Зачем писать новый код с async/await?

S>> Просто при print задействован контроллер, а не CPU.
S>>Операционная система — аппаратное обеспечение ввода-вывода
·>Речь о коде на языке программирования идёт, а не об операционной системе.

Мы говорим об асинхронных методах, которые используют операции ввода вывода. Ты же спрашиваешь зачем использовать асинхронный код.

S>>>> Ты не читатель. Я как раз и говорю, что виртуальные потоки хороши для старого синхронного кода.
S>>·>С этим я и не спорю. И это офигенное преимущество — берём старый код и запускаем параллельно ничего не стесняясь.
S>>С этим никто не спорит. Об этом я тебе сразу и писал. Проблема в поддержке старого и нового.
S>>Так как Task отвечает не только за асинхронность, но и параллельность.
·>_Зачем_ он отвечает за параллельность?

Затем, что Task работает как с потоками так и пулом потоков со своим планировщиком. Так же компилятор создает класс энумератор со state machine с вызовом MoveNext после выполнения await

S>>>>Но для нового кода сложно использовать виртуальные потоки и Task так как задачи используются не только для асинхронного, но и параллельного кода.
S>>·>А вот с этим спорю. В чём сложность-то?
S>> Ну ты сам приводил кучу когда, где использовались различные апи.
·>Э.. И? Выбор api зависит от решаемой задачи. Какой тебе удобно, такой и используй. У тебя есть выбор. Можешь хоть свой API написать. А в случае когда виртуальных потоков нет, приходится устраивать цирк, что ты там нам показывал со всякими асинхронными очередями. Который с треском навернётся, если где-то кто-то как-то внезапно заблокирует что-нибудь.
·>Или для тебя сложностью является наличие выбора?

Вот именно, что апи зависит от задач. Task универсален и легко читаем.

S>>>>То есть код надо переделывать на async/await.
S>>·>Зачем надо?
S>> Ну вот как с тобой разговаривать? Прочитай еще раз внимательно
S>>

S>>Так как Task отвечает не только за асинхронность, но и параллельность.

·>Нет, за параллельность отвечают потоки. Создаёшь много потоков — они выполяются параллельно. То что тебе _приходится_ использовать асинхронность — это недостаток платформенных тредов. Ты их не можешь запускать миллионами, поэтому _приходится_ переписывать "старый" код. Иначе всё просто падает нахрен.

Task это задача. Она отвязана от потоков. Еще раз внимательно читаем про операции ввода вывода, TaskCompletionSource
Что там внутри происходит зависит от планировщика, пула потоков, опций для Task.

Task изнутри: управление потоками в .NET и создание своих планировщиков

Задачи работают через пул потоков или поток ввода вывода или при использовании LongRunning используется отдельный поток.

Как это работает на низком уровне
Приложение запрашивает I/O (например, чтение файла).
Диспетчер I/O создает IRP и буфер системной памяти (SystemBuffer).
Диспетчер отправляет IRP соответствующему драйверу устройства (например, драйверу диска).
Драйвер выполняет операцию с устройством, записывая данные в SystemBuffer (для чтения).
Драйвер завершает IRP, вызывая IoCompleteRequest.
Когда поток готов, Диспетчер I/O копирует данные из SystemBuffer в буфер пользователя (для чтения) и освобождает системный буфер, возобновляя работу потока.