Комментарии 4
epoll мощный механизм, но не совсем полноценный из-за отсутствия механизма получения ассоциированого с fd — epoll_event. Приходится использовать костыли в виде деревьев и т.п., что влечёт дополнительные расходы на поддержание и очистку ресурсов
+2
С poll() или WaitForMultipleObjects() не путаете? В epoll_event как раз есть epoll_data и можно обойтись без деревьев. Скорей не хватает возможности poll'ить семафоры.
0
Нет. Речь о том, что можно назначить epoll_data конкретному дескриптору при вызове epoll_ctl(), но нельзя узнать текущий статус и epoll_data по конретному дескриптору.
Типичный сценарий:
- Создать объект, связанный с дескриптором, засунуть в epoll_data и вызвать
epoll_ctl(..., EPOLL_CTL_ADD, ...)
. - Поработать с дескриптором.
- Удалить дескриптор из epoll, вызвав
epoll_ctl(..., EPOLL_CTL_DEL, ...)
, после чего удалить объект.
Так вот, было бы удобно, чтобы при удалении дескриптора из epoll возвращалось старое значение epoll_data.
Другой сценарий: для одного и то же дескриптора постоянно добавляются и удаляются события, связанные с чтением и записью. При этом оба они разделяют одно и то же значение epoll_data. То есть приходится локально хранить и анализовать маску событий. Проблема решается дублированием дескрипторов и использованием одного только на чтение, а другого — только на запись. Но это расточительство.
+1
del
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация epoll, часть 2