Реализация epoll, часть 2

[Zekori]

epoll мощный механизм, но не совсем полноценный из-за отсутствия механизма получения ассоциированого с fd — epoll_event. Приходится использовать костыли в виде деревьев и т.п., что влечёт дополнительные расходы на поддержание и очистку ресурсов

[z3apa3a]

С poll() или WaitForMultipleObjects() не путаете? В epoll_event как раз есть epoll_data и можно обойтись без деревьев. Скорей не хватает возможности poll'ить семафоры.

[DistortNeo]

Нет. Речь о том, что можно назначить epoll_data конкретному дескриптору при вызове epoll_ctl(), но нельзя узнать текущий статус и epoll_data по конретному дескриптору.

Типичный сценарий:

1. Создать объект, связанный с дескриптором, засунуть в epoll_data и вызвать epoll_ctl(..., EPOLL_CTL_ADD, ...).
2. Поработать с дескриптором.
3. Удалить дескриптор из epoll, вызвав epoll_ctl(..., EPOLL_CTL_DEL, ...), после чего удалить объект.

Так вот, было бы удобно, чтобы при удалении дескриптора из epoll возвращалось старое значение epoll_data.

Другой сценарий: для одного и то же дескриптора постоянно добавляются и удаляются события, связанные с чтением и записью. При этом оба они разделяют одно и то же значение epoll_data. То есть приходится локально хранить и анализовать маску событий. Проблема решается дублированием дескрипторов и использованием одного только на чтение, а другого — только на запись. Но это расточительство.

[z3apa3a]

del