Комментарии 10
В чем смысл писать 1001 пособие?
Ещё и примеры плохому учат...
Интересно, для кого все это? Если для самых маленьких, которые не умеют читать файл, то они и не поймут нихрена, что в этих кусках кода написано, разбавленными скупыми комментариями. Зачем нужны потоки, когда можно хоба и ReadAllText одной командой сделать. Что за хрень такая async, и utf8. В чем отличие BinaryReader/BinaryWriter от StreamReader/StreamWriter - ведь и там и там байты. Ну и еще то, что наверняка взорвет мозг новичку: и Stream, и Thread по-русски называть одним и тем-же словом: потоки. :)
Ну а для тех, кто знает ответы на эти вопросы, они и с файлами работать уже давно умеют. В общем, не понятно, для кого именно статья написана.
На самом деле прикольно,респект за старания,но можно конкретность ввести,мол когда и что лучше использовать,я по крайне мере этого не понимаю
Интересно бы понять преимущества async операций ввода-вывода. Ведь данные диск нам всё-равно быстрее, чем может, не вернёт. Соответственно, продолжать дальше мы по-любому не можем. Ну ладно, мы освободили текущий поток для чего-то ещё. Если этого чего-то ещё нет - то и освобождать некому. Если наш дргуой код (который не ждёт данные, а делает что-то ещё) мы и так забросили в другой поток, тут опять мы ничего не выигрываем. А async вызов - это лишнее переключение контекста и просто так не даётся (ну смотря как оно реализовано, может быть через WinAPI overlapped i/o).
Есть там ещё какая-то заморочка со therad pool когда мы реализуем web сервис например. Вместо создание нового потока для нового запроса фреймворк может как-то заиспользовать уже имеющийся, который висит на ожидании данных. Но это всё туманно. Может есть benchmark'и какие-нибудь с циферками, где можно выйгрыш посмотреть?
Соответственно, продолжать дальше мы по-любому не можем
Вот ваш код на UI-потоке. Пользователь клацнул кнопку - открыть файл. Файл - 100500 гигабайт. Этот UI-поток начал чтение с диска и ждет пока все прочитается. Для пользователя выглядит как будто все зависло. В диспетчере задач - не отвечает. Пользователь не дожидается, убивает ее через диспечер.
Вот чтобы не блокировать основной поток - и нужны асинхронные операции.
Дополнительно, при большом количестве IO, мы более рационально используем потоки, если используем тот же самый async-await, зачем нам целый тред, который ничего не делает, и чего-то ждет, если он может что-то полезное делать пока IO-операция ожидает завершения?
Это всё понятно, вопрос не про UI поток. У меня нет UI потока. У меня Web-Service. Он на запрос должен прочитать файл на 100500 гигабайт и вернуть ответ. Какое преимущество async IO в данном случае, вопрос был об этом.
Для веба он дает вторую часть что в "дополнительно".
Потоки - дорогие. При большой нагрузке - большое времени будет тратится на переключение контекста, чем на обработку самого запроса. C10k/C10M или как-то так обзывается в вебе.
Асинхронщина - позволяет уменьшить это самое число потоков, ведь когда запустилась асинхронная операция - этот поток может не ждать пока она завершиться, а переключиться на обработку других запросов. Когда обработка завершится - планировщик, в зависимости от настроек, либо найдет незанятый поток и тот продолжит выполнение, либо будет ждать пока вызвавший поток будет готов к обработке результата.
Через стримы итак все умеют, лучше бы рассказали как это правильно через Pipe делать
Основы работы с файлами и потоками в C#