Чем чтение сокетов отличается от чтения файлов?

Я просто планировал переписать некоторый код Python, в котором я опрашивал файл на наличие изменений. Я хотел переписать его как упражнение для asyncio, и концептуальная идея заключалась в том, чтобы сделать неблокирующее чтение файла, которое даст результат. Как только данные станут доступны, цикл обработки событий продолжит выполнение сопрограммы.

Затем я обнаружил, что асинхронные операции с файлами — это не то, что делают люди. ref.

Но я не мог понять, какова мотивация такого поведения и чем оно отличается от сокетов.

Пример сокета:

Чтение сокета выполняется сопрограммой до тех пор, пока данные не будут готовы. Готово означает, что оно фактически прибыло в недетерминированное время откуда-то из Интернета.

Почему бы не также для чтения файла:

Чтение файла выполняется сопрограммой до тех пор, пока данные не будут готовы. Готово означает, что оно действительно прибыло в недетерминированное время откуда-то с жесткого диска компьютера.

  • Является ли это унаследованным от устаревшего кода поведением, которое достаточно хорошо работает с блокирующими вызовами?

  • Это как-то связано с файлами символов и блоков?

  • Как насчет файлов символьных устройств, скажем, файла, представляющего соединение UART? Будет ли здесь также применяться безфайловый ввод-вывод?


linux asynchronous python-asyncio linux-device-driver
person TheMeaningfulEngineer    schedule 23.06.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Определенно не полный ответ, а некоторые мысли, которые слишком велики для комментария.

  • Асинхронное программирование изначально было наиболее полезным в сетевых системах/сокетах. В то время как кто-то очень редко имеет 100 000 открытых файлов и хочет читать из них все асинхронно, чат-серверы (или другие, которые обрабатывают в основном бездействующие соединения) вполне могут иметь 100 000+ таких соединений. Безусловно, асинхронное программирование к настоящему времени является «стилем», который позволяет избежать многих проблем с программированием на основе потоков, но это не то, с чего оно началось (хотя у меня нет доказательств этого утверждения).
  • В случае файлов, когда кто-то запрашивает информацию, она должна быть получена в какой-то момент в ближайшем будущем. Возможно, это сравнимо с выполнением HTTP-запроса, когда вы ожидаете ответа и, возможно, просто ожидаете его синхронным образом. С другой стороны, сокет может быть открыт только для push-сообщений, где нет никаких ожиданий относительно того, когда (если вообще) придет сообщение. Для некоторых специальных файлов это также может быть верно, но я ожидаю, что в этом случае будет доступно другое асинхронное сообщение, после которого должно произойти синхронное чтение (например, iNotify для обычных файлов, никогда не просматривал специальные файлы).
  • Я бы сказал, что если вы не знаете, что делаете, на самом деле очень плохая идея делать массивный параллельный доступ к файлам. Таким образом, сокеты могут быть полезны, поскольку вы можете подключаться к разным машинам. Выполняя массовый параллельный файловый ввод-вывод, возможно, вы хотите, чтобы ОС все равно сериализовала запросы для вас (вы когда-нибудь пытались одновременно скопировать 2 больших файла с компакт-диска;))?

Как я уже сказал, однозначного ответа нет, просто некоторые мысли по этому поводу.

person Claude    schedule 25.06.2017
comment
Параллельность хороша почти для всего в наши дни. Даже механические жесткие диски принимают 16 запросов с использованием NCQ, и у них достаточно буферной оперативной памяти, так что даже если все 16 находятся на разных дорожках, он может хранить все 16 полных дорожек в буфере. - person Zan Lynx; 26.06.2017
comment
Я понимаю, что некоторые параллельные вызовы имеют смысл для файлов. Хотя и не массово. Асинхронное программирование действительно окупается в момент, когда потоки потребляют слишком много памяти, при 100 тысячах одновременных подключений или около того. Не хочу делать это на жестком диске или ssd. Для файлов, кэшированных в памяти, вы могли бы, но тогда зачем в любом случае использовать асинхронный доступ, нет ожидания ввода-вывода. - person Claude; 26.06.2017
comment
Хорошо, это относится к чтению с диска, но есть ли у нас представление о файлах устройства? - person TheMeaningfulEngineer; 29.06.2017
comment
Я не думаю, что есть много случаев, когда вы хотели бы читать из 100 000 файлов устройств одновременно. По этой причине я думаю, что отсутствие огромной потребности привело к тому, что над этим не было проделано никакой работы. Но опять же, только предчувствие. - person Claude; 30.06.2017