порядок событий epoll от epoll_wait - PullRequest
0 голосов
/ 18 мая 2018

Я перенес программу в epoll из select, чтобы увеличить количество сокетов, которые мы можем обработать.Я добавил сокеты в epoll FD и могу счастливо читать и писать.

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

Пример: скажем, у меня есть 10 сокетов, подключенных и добавленных к epoll fd.У меня достаточно памяти только для 5 epoll_event структур.Предположим, что за время между epoll_wait все 10 сокетов получают данные.Первый epoll_wait вернет 5 epoll_event структур для обработки, скажем, это сокеты 1-5.Я обрабатываю эти 5 сокетов, и при этом поступает больше данных, и все 10 сокетов имеют больше данных для чтения.Я снова ввожу epoll_wait и получаю еще 5 epoll_event структур.

Мой вопрос: какие 5 сокетов я получу при втором вызове epoll_wait.Это будут сокеты 1-5, потому что они были добавлены в epoll FD первыми?Или я получу сокеты 6-10, потому что эти события были вызваны до того, как в сокеты 1-5 поступило больше данных?

По сути, epoll_wait похоже на очередь FIFO или просто сканирует внутренний список сокетов(и тем самым отдавая предпочтение первым сокетам в списке).

РЕДАКТИРОВАТЬ: Это ядро ​​Linux v4.9.62

Ответы [ 2 ]

0 голосов
/ 22 июня 2018

Наблюдение @jxh о поведении является правильным, и поведение давно установлено (и было изначально задумано, если я правильно вспоминаю свои беседы по электронной почте с разработчиком, Давиде Либензи, много лет назад). К сожалению, это не было задокументировано до сих пор. Но я исправил это в следующем выпуске справочных страниц, где epoll_wait (2) будет содержать текст:

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

0 голосов
/ 18 мая 2018

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

Исходя из этого, ответ таков, что порядок дескрипторов основан на порядке, в котором они стали готовы.

...