В relibc появился recvmsg, а recvfrom переписан через него и перестал зависать

В relibc реализован recvmsg — приём данных вместе со служебными сведениями, включая адрес отправителя и дескрипторы. recvfrom переписан через него, и зависание в нём устранено.

Зачем нужен recvmsg, если есть recvfrom

recvfrom принимает данные и возвращает адрес отправителя. recvmsg принимает то же самое, но вместе с данными приходят дополнительные сведения — так называемые вспомогательные данные.

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

Что было не так

Функции не было. А recvfrom, который раньше был единственным способом принять UDP-пакет, при определённых условиях зависал. Для программы это выглядит как потеря связи с сетью без всякой ошибки — худший вид отказа, потому что его легко списать на внешнюю причину.

Как исправлено

Добавлена обработка recvmsg в схемы TCP и UDP. Затем recvfrom переписан так, что он идёт через новый обработчик, — и зависание исчезло вместе с дублирующимся кодом.

Побочно в том же месяце появилась возможность читать IP-адрес отправителя прямо из вспомогательных данных UDP-сообщения. Раньше, как отмечено в сводке за апрель, адрес был единственным носителем состояния сокета, и его приходилось добывать отдельным вызовом.

Оригинал

Коммит Merge branch 'impl_recvmsg' into 'master' от 25 марта 2026 года в репозитории redox-os/relibc; обработчики в схемах — 24 марта в redox-os/base; сводка «This Month in Redox — March 2026», разделы «Relibc Improvements» и «Networking Improvements»