Многопоточные процессы и close()¶

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

Кроме того, рассмотрим следующий сценарий, в котором два потока выполняют операции с одним и тем же файловым дескриптором:

(1)

Один поток блокируется при системном вызове ввода-вывода для файлового дескриптора. Например, он пытается выполнить write(2) (запись) в канал, который уже заполнен, или пытается выполнить read(2) (чтение) из потокового сокета, в котором в данный момент нет доступных данных.

(2)

Другой поток закрывает файловый дескриптор.

Поведение в этой ситуации различается в разных системах. В некоторых системах, когда файловый дескриптор закрыт, системный вызов блокировки немедленно возвращается с ошибкой.

В Linux (и, возможно, в некоторых других системах) поведение иное: системный вызов блокировки ввода-вывода содержит ссылку на дескриптор базового открытого файла и эта ссылка сохраняет дескриптор открытым до завершения системного вызова ввода-вывода (смотрите open(2) для обсуждения открытого файлового дескриптора). Таким образом, блокирующий системный вызов в первом потоке может успешно завершиться после close() во втором потоке.

Обработка ошибки, возвращённой close()¶

Аккуратный программист всегда проверяет возвращаемое close() значение, так как очень вероятно, что об ошибках предыдущей операции write(2) будет сообщено только при последнем вызове close(), который освобождает дескриптор открытого файла. Невыполнение проверки возвращаемого значение при закрытии файла может привести к silent (неучтённой) потере данных. Это особенно часто встречается с NFS и с дисковыми квотами.

Однако заметим, что возвращаемая ошибка должна использоваться только для диагностики (т. е. предупреждать приложение, что, возможно, есть незаконченные операции ввода-вывода или произошла ошибка ввода-вывода) или для исправления (например, повторной записи файла, или для создания резервной копии).

Повторный вызов close() после получения ошибки делать не стоит, так как это может привести к закрытию повторно использованного файлового дескриптора другого потока. Это может произойти из-за того, что ядро Linux always освобождает файловый дескриптор в самом начале операции закрытия, делая его доступным для повторного использования. Шаги, которые могут вернуть ошибку, такие как сброс данных в файловую систему или в устройство, происходят только после операции закрытия.

Многие другие реализации поступают схожим образом и всегда закрывают файловый дескриптор (за исключением случая EBADF, означающего некорректный файловый дескриптор) даже, если они затем возвратят ошибку close(). В POSIX.1 ничего не сказано на этот счёт, но есть планы узаконить такое поведение в следующем выпуске стандарта.

Аккуратный программист, который хочет узнать об ошибках ввода-вывода, перед вызовом close() вызовет fsync(2).

Ошибка EINTR является особым случаем. Об EINTR в POSIX.1-2008 сказано:

Этим допускается режим работы, действующий в Linux и многих других реализациях, где как и при других ошибках, которые может вернуть close(), файловый дескриптор гарантированно закрывается. Однако, это также допускает и другой режим: реализация возвращает ошибку EINTR и оставляет файловый дескриптор открытым (согласно документации, так делает close() в HP-UX). Затем вызывающая сторона должна еще раз использовать close(), чтобы закрыть файловый дескриптор, чтобы избежать утечки файлового дескриптора. Такое расхождение в поведении реализаций является сложным препятствием для переносимых приложений, так как во многих реализациях close() не должен вызываться ещё раз после получения ошибки EINTR и, по крайней мере, в одном случае необходимо снова вызвать программу close(). Есть планы разгадать эту загадку в следующей большой версии стандарта POSIX.1.