Да, дескриптор файла (в системах Unix, POSIX, ...) известен ядру и всему текущему процессу.Каждый процесс имеет свою собственную таблицу дескрипторов файлов и виртуальное адресное пространство .
. В Linux вы можете использовать proc (5) для запроса обоихфайловые дескрипторы и виртуальное адресное пространство какого-либо процесса.Для процесса pid 1234 используйте /proc/1234/fd/
& /proc/1234/fdinfo/
, чтобы понять его файловые дескрипторы и их таблицу, и /proc/1234/maps
& /proc/1234/smaps
, чтобы понять его виртуальное адресное пространство.
То есть, если вызываемая функцияclose
-s это, вы не должны использовать его больше.Конечно, вы можете активировать его (с некоторыми другими open
, socket
, dup
, возвращающими его).
Поэтому вам необходимо определить, задокументировать и явные соглашения о close
-ing-обязанностях(как вы делаете с free
-ing указателями).Читайте также о RAII .
В этом аспекте close
немного похож на free
: это делает недействительным значение (дескриптор файла для close
указатель на free
) передан на него.По возможности вы можете установить дескриптор файла на -1 (или другое недопустимое значение) после успешного close (2) , например, код close(fd); fd = -1;
.По тем же причинам я также делаю free(ptr), ptr = NULL;
, когда это возможно.
Кстати, я полагаю, Unix или POSIX (или Linux) системы.Я не знаю Windows, и у нее совсем другое представление о файловых дескрипторах и сокетах .