Дескрипторы в ОС

я тролль, но сейчас всё серьезно.

читал сказку про мальчика который кричал «волки»?

Если у тебя какая-нить блоатварь типа гнома или системд то забей, всё равно всё будет плохо. Дескрипторы это открытые файлы.

Дескриптор это по сути файловый порт. Как сетевой, только файловый. Первый дескриптор это ввод, второй - вывод, и там дальше ещё какие-то, не помню

1

2

Файловые дескриптор это как сетевой порт. Дескриптор процесса это параметры для процесса установленные операционной системой.

Дескриптор, он же хэндл(в windows терминологии) - это способ инкапсуляции.

Например, у тебя есть в ядре структура описывающая файл, она хранится где-то в области памяти ядра буквально как указатель на структуру. Но, чтобы твои кривые ручки из юзерленда не попортили эту структуру (ну и не получили segfault), введён мэппинг «чиселко»:«указатель на структуру». Чиселки даются в юзерлэнд, а внутри вызовов ядра конвертируются обратно в указатели. Дескриптор не обязан быть чиселком, но чаще всего это всё-таки оно.

Т.е. это буквально способ надёжно разделить два слоя, ценой определённых накладных расходов на мэппинг. Так делают не только в ситуации юзерлэнд<->ядро, но и в случаях например клиент <-> проприетарная библиотека.

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

Файловый дескриптор — это неотрицательное целое число. Когда создается новый поток ввода-вывода, ядро возвращает процессу, создавшему поток ввода-вывода, его файловый дескриптор.

То есть важнее количество дескрипторов, а не количество процессов? Потому что один процесс может открыть несколько дескрипторов?

To count the number of open file handles of any sort, type the following command:

# lsof | wc -l

Это оно? Чем больше число, тем больше захламлен дистрибутив, если учтановка чистая, «из коробки» ?

если учтановка чистая, «из коробки»

пхахаха вы видели выхлоп mount на современном дистрибутиве?

UNIX: Everything is a file

systemd: Everything is a filesystem

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

Короче

Запущенный файл == минимум плюс один процесс. Открытый файл == минимум плюс один дескриптор.

И то и то можно ограничить глобально для системы. При упоре в лимит 100 процессов запустятся, а 101вый будет послан в жопу. Также 100 файлов откроются, а 101вый ты не откроешь уже пока не закроешь другой.

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

Причём здесь захламлённость?

Я за полминуты могу написать скрипт, который откроет на чтение абсолютно все файлы на файловой системе и по несколько раз. Захламлённее система от этого не станет.

А на что влияет количество открытых дескрипторов? Есть какая-то корреляция с временем отклика и производительностью?

Незнаю понятно будет или нет я оффтопике загнал свой Message в заголовок FireFox перебором всех сообщений винды и фильтровал по дескрпитору. То есть это как уникальный идентификатор для любого элемена во вселенной в системе.

Они кушают память. Если бы не было лимитов, можно было бы запустить в бесконечном цикле скриптик и съесть всю оперативу, например.

Всегда думал, что дескрипторы это указатели, джампы.

Это тупо индекс, по которому ядро получает структуру, хранящуюся в памяти ядра.

procedure TForm1.Button1Click(Sender: TObject);
const s = 'text';
begin
  SendMessage(FindWindow(nil, 'Mozilla Firefox'), WM_SETTEXT,
                Length(s), integer(@s[1]));
end;

end.

С форума программистов, мне помогли найти. FindWindow возвращает дексриптор заголовка окна и SendMessage отпавляет сообщение любому элементу по дескриптору. Тут какой-то лютый хак используются, я сейчас слёту не могу даже сообразить.

В первую очередь дескриптор — это идентификатор объекта ядра. Это может быть открытый файл, сокет, мютекс, или кнопка в GUI-окне (последнее не обязательно имеет дескриптор даже в Windows).

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

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

Дескриптор — это та штука, которую приходится использовать, не имея нормального объектного представления сущности. Если язык или среда исполнения кода в целом не позволяет сделать так:

file.read(&buf, size);

то делают так:

read(file, &buf, size);

Т.е. дескриптор (file) — это такой костыль, который позволяет привязать конкретный вызов метода к конкретной сущности.

По вашему вопросу. Большое количество дескрипторов в системе еще не обозначает большое количество потребляемых ею ресурсов. Тем более, что большая часть дескрипторов сознается запущенными процессами, а не ядром.

Напрямую сравнивать количество дескрипторов тоже нельзя, потому что за разными дескрипторами стоят совсем разные объекты, а, следовательно, и расходы ресурсов. Открытый файл почти ничего не стоит. А вот дескриптор процесса — это совсем другой объем ресурсов, за ним могут стоять гигабайты занятой памяти и 100% утилизации мощности процессора (а могут и не стоять).

Количество дескрипторов в любой системе, кстати, ограничено. И далеко не разрядностью соответствующего типа данных. Это тянет за собой отдельные проблемы. В Linux, например, количество открытых сокетов по-умолчанию ограничено таким значением, что DDoS-атаки можно выполнять весьма скромными силами, просто превысив это число.

Количество дескрипторов (или его увеличение) - это косвенный, приблизительный и нелинейный, но все равно показатель количества потенциальных проблем и степени отдаления вычислительных действий системы от реального времени