Почему файловые дескрипторы такие дорогие ресурсы?

Question

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

Answer 1

Закрытие файла также сбрасывает записи на диск - ну, в любом случае, с точки зрения вашего приложения. После закрытия файла приложение может аварийно завершить работу, пока сама система не аварийно завершится, изменения не будут потеряны. Так что не стоит разрешать GC закрывать файлы на досуге. Даже если это может быть технически возможно в наше время.

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

Answer 2

На практике это не может быть сделано, потому что ОС придется выделять намного больше памяти для отслеживания того, какие дескрипторы используются различными процессами. В примере кода C, как показано ниже, я продемонстрирую простую структуру процесса ОС, сохраненную в циклической очереди для примера...

struct ProcessRecord {int ProcessId; CPURegs cpuRegs; TaskPointer ** children; int * baseMemAddress; int sizeOfStack; int sizeOfHeap; int * baseHeapAddress; внутри гранулярность; во время;
  enum State{ Running, Runnable, Zombie ... };
  /* ... здесь еще несколько полей... */
  long *fileHandles;
  long fileHandlesCount;
} Proc;

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

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

Я надеюсь, что это поможет вам понять, почему это не реализовано и не практично.

Надеюсь, что это имеет смысл, С наилучшими пожеланиями, Том.

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

В парадигме Linux сокеты являются файловыми дескрипторами. Есть определенные преимущества для освобождения портов TCP как можно скорее.