Неблокирующий write в файловый дескриптор

А что именно с select() не получилось?

aio_write?

Ты имеешь ввиду в настоящий файл на диске? Нет, там неблокируемый режим не предусмотрен. Ты можешь его эмулировать с помощью тредов, но отменить после таймаута всё равно будет нельзя. То есть ты в своей проге можешь считать «запись не удалась, идём дальше», но write() в другом треде всё равно будет висеть и ждать ответа от диска столько, сколько потребуется, и в итоге выдаст какой-то код возврата.

Упомянутый выше aio_write делает по сути то же самое, только всю возню с тредами прячет внутрь, и менее управляемый чем если ты вручную будешь это делать.

Упомянутый выше aio_write делает по сути то же самое, только всю возню с тредами прячет внутрь,

сомневаюсь. Ты хочешь заказать, что если мне нужно работать с 1000 файлами, то следует создать 1000 потоков, вместо использования AIO? Тогда какой в нем (AIO) смысл?

и менее управляемый чем если ты вручную будешь это делать.

в чем заключается меньшая управляемость?

Смысл в aio такой что он работает из коробки и не требует муторного кодинга. Если у тебя нет больших нагрузок - можешь на нём и остановиться.

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

Если по-современному, посмотри на примеры liburing. Вот что выдаёт $ ./ucontext-cp, например:

./ucontext-cp: infile1 outfile1 [infile2 outfile2 […]]

$ ./ucontext-cp Makefile Makefile.copy helpers.c helpers.c.copy:

copying 2 files...
4->5: readv 1024 bytes from 0
6->7: readv 1024 bytes from 0
4->5: writev 1024 bytes from 0
6->7: writev 1024 bytes from 0
4->5: wait 1s
6->7: wait 1s
4->5: readv 1024 bytes from 1024
6->7: readv 1024 bytes from 1024
4->5: writev 321 bytes from 1024
6->7: writev 383 bytes from 1024
4->5: done with ret code 0
6->7: done with ret code 0
finished with 2 success(es) and 0 failure(s)

Uring пробуй. Еще через io submit можно но там только direct io

Файл на файловой системе samba, я открываю файл для записи, потом начинаю писать поблочно, потом выдергиваю ethernet кабель и зависаю на write секунд на 30, не могу понять где именно этот тайм-аут выставляется.

Таймаут видимо где-то в драйвере smb. Может быть есть в опциях монтирования, а может и только патчить исходник. В write() ты его точно не передашь.

Select, насколько помню, говорит, что сокет свободен для записи, но он ничего не говорит о том, сколько байт можно пихнуть в этот сокет. И не факт, что все эти байты запишутся, да и вообще, не факт, что будут доставлены адресату.

IO - сложная штука. Обычно приходят к тому, что придумывают разные протоколы уже на уровне приложения, чтобы получить почти гарантированную доставку. А если вводить еще и тайм-аут, то уже такой тайм-аут будет работать далеко не на 100%, потому что ты запросто можешь отменить операцию после фактической доставки байтиков адресату, но до получения отчета о самой доставке. Нет здесь транзакционности. Короче, сложно все это…

На правах рекламы. Рекомендую посмотреть на хаскель. К примеру там весь стандартный реализованный на уровне рантайма IO изначально асинхронный, причем код ты пишешь как обычный якобы синхронный, но по факту он будет асинхронным. Конечно, в пределах функций ввода-вывода из стандартной библиотеки, которая поддерживается на уровне рантайма. Там внутри уже сидят всякие select/poll/epoll. Вот так! Классная штука!

Укажи язык, c селектом в сишке - не, такое думаю лучше через отдельный тред делать, поскольку сам по-себе файловый io блокирующий в самой ОС (если я не туплю). С селектом в golang - можно, но это также будет «фейковая» неблокируемость - по принципу покласть болт на результаты операции, которая всё равно будет завершена.