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

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

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

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

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

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

struct ProcessRecord{
  int ProcessId;
  CPURegs cpuRegs;
  TaskPointer **children;
  int *baseMemAddress;
  int sizeOfStack;
  int sizeOfHeap;
  int *baseHeapAddress;
  int granularity;
  int time;
  enum State{ Running, Runnable, Zombie ... };
  /* ...few more fields here... */
  long *fileHandles;
  long fileHandlesCount;
}proc;

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

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

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

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

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