ВН
Ну ему ж нужно совместимое, для него жив наверное =))
Size: a a a
2021 September 05
E
Это неважно. Важно что у меня есть рабочий инструмент из коробки. То что если я хочу пирформанса под платформой Х то мне нужен инструмент специально под платформу х и так понятно.
МК
Да, я забыл. Полл и еполл не работают на файлы. Они типа всегда готовы. А по факту блочат
МК
А, еполл их вобще не хавоет
ВН
Ну я бы сказал например что вообще всё posix api говно, т.к. оно всё синхронное. Я бы всё сделал асинхронным
ВН
А то получается условно асинхронную запись ты сделать можешь, а асинхронный rename скажем - в общем-то нет
МК
Оно сложнее
МК
Труднее дебажить
МК
МК
Синхронное нужно. Но и асинхронное тоже
ВН
Ну либо сделать встроенный какой-то вариант асинхронного
ВН
В стандарт
МК
Тут согласен
AK
И везде сделано по-своему. В винде (например) оно сделано через т.н. overlapped I/O со своеим собственным интерфейсом. Идите и дое...есь до майкрософта, если такие резкие
AK
Не так. Данные файлов - вот они есть, поэтому вызов не блокируется на неопределенное ожидание удаленной стороны. Тебе никто не обещал что вызов не пойдет к внешним устройствам, тебе обещают только что вызов гарантированно вернет данные без ожидания удаленной стороны (нуу, кроме сетевых ФС, самом собой)
AK
Ну вот ты мух и котлет то не мешай. Асинхронное оно с точки зрения твоего приложения - ты сделал вызов указав методику нотификации и когда нотификация пришла проверяешь результат. Где оно внутри ядра синхронное и где нет - это тебя не волнует.
AK
У тебя вообще может быть например отдельный I/O thread в который твоя библиотека aio которую дергает твоя программа сгружает весь I/O, и который внутри себя где-то делает синхронно, где-то через io_submit, где-то еще как-нибудь, но твой основной тред при этом не ждет. Собственно, libaio и получается
ВН
Ну вот мой поинт в том, что пусть лучше те, кому надо, эмулируют синхронное поведение через асинхронный интерфейс, чем наоборот
МК
Так мы придем к тому что синхронных сисколлов не останется
МК
И программировать будет тяжело