Назначение дескриптора файла в C
Когда сокеты создаются или файлы открываются / создаются в C, гарантированно ли дескриптор файла, назначенный сокету / файлу, будет дескриптором с наименьшим значением из доступных? Что в этой связи говорит спецификация C о назначении файловых дескрипторов?
Ответы 6
Не думаю, что вы найдете это в спецификации C, скорее, в спецификации вашей ОС. Мой опыт работы с Linux показал, что он всегда самый низкий.
Я отвечу на это еще одним вопросом - почему это имеет значение? Вы не должны сравнивать файловый дескриптор с чем-либо (кроме проверки на stdin / stdout / stderr) или выполнять с ним математические вычисления. Пока он умещается в int (и это гарантировано), это все, что вам действительно нужно знать.
Стив М. прав; C не имеет понятия о сокетах, и его функции ввода-вывода файлов используют [указатель на] FILE-объект, а не дескриптор.
На самом деле C имеет два способа чтения файлов: один с объектом FILE, а другой с файловым дескриптором.
Основанный на файловом дескрипторе способ - это интерфейс системного вызова, предоставляемый Unix API, а не часть собственно C.
Не гарантируется, что он будет самым низким и зависит от реализации (1). Однако в целом процедура, назначающая дескрипторы открытых файлов, использует метод, который дает вам первое открытие. Может случиться так, что сразу после того, как несколько более низких будут освобождены, у вас останется более высокий дескриптор, чем вы могли ожидать.
Единственная причина, по которой я могу это знать, - это функция выбора, которая ускоряется, если вы передаете ей самый высокий дескриптор файла, который вам нужно проверить.
(1) Обратите внимание, что реализации, соответствующие стандарту IEEE, действительно гарантируют наименьший неиспользуемый дескриптор для файлов, но это может не относиться к сокетам. Не каждая реализация следует стандарту IEEE для open (), поэтому, если вы пишете переносимое программное обеспечение, лучше не зависеть от него.
Вызов open () гарантированно возвращает наименьший доступный дескриптор файла: opengroup.org/onlinepubs/009695399/functions/open.html Похоже, такой гарантии для сокетов нет.
Имеется в виду «стандарт IEEE» - POSIX. Об этом стоит упомянуть ...
@aib - open (), close (), lseek (), read (), write () - все они используют дескрипторы файлов. Я почти никогда не использую потоки для ввода-вывода.
@Kyle это имеет значение из-за таких операторов, как select (). Знание самого старшего дескриптора может улучшить производительность.
Спецификация C говорит, что это зависит от реализации. Если вы смотрите на реализацию Unix, страница руководства для open (2) говорит: «Дескриптор файла, возвращаемый успешным вызовом, будет дескриптором файла с наименьшим номером, который в данный момент не открыт для процесса».
Это помогает, если вы пытаетесь прикрепить определенный файл к определенному дескриптору. Скажем, вы хотите перенаправить stderr на / dev / null. Что-то вроде
закрыть (2); open ("/ dev / null", O_WRONLY);
должен это сделать. Вы, конечно, должны захватить fd, возвращаемый open, и убедиться, что это 2.
Или используйте dup2, чтобы гарантировать, что вы назначили правильный поток намеченному файловому дескриптору.
Если ваша программа использует потоки и у вас нет жесткого контроля над тем, что делают другие потоки, dup2 - единственный безопасный способ. close / open вводит состояние гонки, во время которого другой поток может получить дескриптор файла.
Не правда. Использование его с select требует, чтобы он вписался в объект
fd_set. А поскольку POSIX требует, чтобы файловые дескрипторы выделялись последовательно, вы можете аналогичным образом использовать свои собственные объекты битового массива для хранения наборов файловых дескрипторов, что вы можете сделать переносимо.