Потому что без колбэка почему то не получается вернуть упрааление сразу

Ну окей покажи вызов "дождаться завершения open"

Ты мыслишь в какой-то юниксовой системе понятий, как будто иначе и быть не может.
Асинхронный опен можно прикостылить даже в ту же фрю/линь, просто работать оно будет кривее, чем ожидают люди

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

Не в юниксовой а вмс/рт11. Если бы у тебя бвл доступ к инстпляции зос ч бы просто предложид мделать опен на дискетке и замерить время

зачем это в rt системе? rt это не про асинхронность вообще

Ну вообще POSIX.1b (rt расширение) как раз таки и про асинхронный ввод-вывод тоже

там и описывается posix aio, который в glibc сделан через жопу в юзер спейс оберткой над синхронным через треды

в posix aio нет асинхронного open()

ну и вообще ничего асинхронного работающего с путями

close/rmdir/mv/и т п

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

ну вот не сделали. вероятно слишком уж много в говноядрах переделывать придется для поддержки

Дело, думаю, не в том, что там много чего надо перепилить, а в том, что это противоречит идеологии, к которой привыкли в современном мире. А именно: опен так-то нужен только для двух вещей -- для оптимизации лукапа файла и проверки всяких прав доступа (чтобы при rw было достаточно только проверить их по маске с теми, которые сохранены в fd) и для того, чтобы приложение знало, что всё с файлом хорошо и можно с ним работать (плюс, для синхронизации с другими процессами в части доступа к файлу). Асинхронный опен ломает эту концепцию в том смысле, что приложение не сможет понять, всё ли нормально. То есть для широких масс такой подход неприменим и асинхронный опен в общем случае сразу за собой будет вызывать блокирующий вызов, чтобы убедиться, что опен получился.

Если всё же пофантазировать, то никто не мешает в частном случае слегка пропатчить ядро (здесь и далее -- в терминах фряшки): во время опена делать только finstall, а в fde добавить флажок, что опен ещё в процессе. Все операции по rw на такой fd ставить в event очередь (так же, как внутри vfs_aio). Если запрос синхронный, то можно также заблокировать процесс, пока опен не закончится. Причем, когда namei (единственное, что может тормозить и из-за чего ты вообще поднял этот разговор) отработает, флажок внутри fde надо поменять либо на «опен успешен», либо на «опен сломался: eperm, enofile, ну и т.д). В зависимости от этого флажка либо позволять, либо не позволять ставить в очередь новые rw реквесты. Если в очереди есть реквесты с этим фд (т.е. когда namei таки выполнится, надо будет пробежать через весь лист), а опен сломался, то на все можно сразу ответить с ошибкой (в смысле, установить готовность и если просят -- отправить нотификацию в тред, что fd готов) и при следующем rw (ровно как и при select/poll/...) уже вернуть, что это не rw сломался, а опен. Очевидно, останется на стороне приложения самостоятельно это ловить и вызывать close для fd, которые не получилось открыть. Make sense?

А что касается инсталляций zos, до которых я могу теоретически дотянуться, там везде стоят dlm, набитые nvme scm и на глаз будет довольно трудно определить, насколько оно тормозит :)

Кстати, в jdl (job description language, если я правильно помню название ЭТОГО) проблемы асинхронного опена нет: любая джоба уже в хедере имеет полный список файлов с которыми работает. Немного не динамичненько, но зато никакие опены не нужны. Вся суть мейнфреймов...

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

Это рассказываешь про трудности для приложения варианта вернули неготовый fd. Да, для приложения это сложно. Поэтому возвращать надо готовый.

Но я подозреваю что если ядро исходно не точилось под асинхронщину тут то переделывать будет надо дохуя

Ну либо идеологически непонятно как нотифицировать

Ну, наши-то ядра (имею ввиду фрю и линь) более-менее норм сейчас асинхронно работают. Я бы даже сказал так: вся внутрянка там и так асинхронная. Синхронность -- это иллюзия, которую прилепили сбоку

Ну да, если отталкиваться, что возвращать надо готовый, тогда надо костылить какую-то нотификацию и как мне кажется, это куда больше изменений в коде :)