Читаем Linux API. Исчерпывающее руководство полностью

Вызов select() традиционно является более популярным по сравнению с poll(). В наши дни оба интерфейса входят в стандарт SUSv3 и широко применяются в современных системах. Тем не менее, как отмечалось в подразделе 59.2.3, поведение вызова poll() может варьироваться в зависимости от реализации.

Производительность

Производительность вызовов poll() и select() одинакова, если выполняется любое из следующих условий:

• диапазон файловых дескрипторов, за которыми нужно наблюдать, достаточно узок (выбран небольшой максимальный номер дескриптора);

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

Однако производительность вызовов select() и poll() может заметно отличаться в ситуации, когда набор отслеживаемых файловых дескрипторов разрежен, то есть если максимальный номер дескриптора, N, является большим, но в диапазоне от 0 до N находится один или несколько элементов. В данном случае poll() может работать быстрее, чем select(). Чтобы понять, почему так происходит, рассмотрим передаваемые этим двум системным вызовам аргументы. Вызов select() принимает один или несколько наборов с файловыми дескрипторами и целое число, nfds, которое на единицу больше, чем максимальный номер отслеживаемых дескрипторов в каждом из наборов. Значение nfds не зависит от того, наблюдаем ли мы за всеми дескрипторами в диапазоне от 0 до (nfds — 1) или только за одним из них, (nfds — 1). В обоих случаях ядро должно проверить элементы nfds в каждом из наборов, чтобы определить, какие именно дескрипторы нужно контролировать. Для сравнения: вызову poll() передаются лишь те дескрипторы, которые нас интересуют, и ядро проверяет только их.

Мы еще вернемся к производительности вызовов select() и poll() в подразделе 59.4.5, где они будут сравниваться с интерфейсом epoll.

59.2.5. Проблемы, присущие вызовам select() и poll()

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

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

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

• После вызова select() или poll() программа должна проверить каждый элемент полученной структуры данных, чтобы узнать, какие файловые дескрипторы являются готовыми.

Следствием приведенных выше замечаний является тот факт, что процессорное время, которое уходит на выполнение вызовов select() и poll(), прямо пропорционально количеству отслеживаемых файловых дескрипторов (больше подробностей см. в подразделе 59.4.5). И если это количество велико, то у нас могут возникнуть проблемы.

Плохое масштабирование вызовов select() и poll() вызвано простым ограничением их программных интерфейсов: обычно для проверки одного и того же набора файловых дескрипторов выполняются циклические вызовы; но ядро не запоминает содержимое данного набора, поэтому его нужно передавать снова и снова.

Ввод/вывод на основе сигналов и интерфейс epoll (будут рассмотрены в следующих разделах) позволяют ядру записывать набор файловых дескрипторов, в которых заинтересован процесс. Это устраняет проблемы с масштабированием, присущие вызовам select() и poll(), и обеспечивает производительность, зависящую не от количества отслеживаемых дескрипторов, а от частоты событий ввода/вывода. Следовательно, ввод/вывод на основе сигналов и интерфейс epoll являются более предпочтительными в ситуациях, когда дескрипторов слишком много.

59.3. Ввод/вывод на основе сигналов