Если один поток (скажем, X) ожидает epoll_wait()
может другой поток (скажем, Y) делает вызов epoll_ctl()
зарегистрировать интерес в файловом дескрипторе 9
, Может ли предыдущий звонок epoll_wait()
в потоке X вернуть дескриптор файла 9
добавил по теме Y? Первоначальный вызов epoll_wait()
никогда не возвращался в середине в любой точке.
Теперь я хочу сравнить это и задать связанные вопросы по двум другим опросам в операционных системах. poll()
а также kqueue
poll()
системный вызов?epoll_ctl()
является потокобезопасным, и поток X может безопасно вызвать epoll_ctl()
и позвонить epoll_wait()
вернуть ли дескриптор файла 9
готов к вводу / выводу. Разделение функции для объявления интереса к дескриптору файла и функции ожидания — вот что делает эту функцию удивительной. Но люди часто ссылаются на kqueue
а также epoll
как используется для той же функциональности. тем не мение kqueue
не имеет отдельной функции для объявления заинтересованности в получении обратной связи по событию для дескриптора. Кто-нибудь знает как kqueue
может быть использован аналогично epoll
? epoll
Кажется, на данный момент это лучший потокобезопасный вариант, если он допускает потокобезопасное «объявление процентов» От man epoll_wait:
Хотя один поток блокируется при вызове epoll_pwait (), другой поток может добавить файловый дескриптор в ожидаемый экземпляр epoll. Если новый дескриптор файла станет готовым, он вызовет вызов функции epoll_wait ().
Так epoll_wait
отслеживает добавленный файловый дескриптор, пока он ожидает.
Такое поведение не может быть достигнуто poll () / select (), так как они читают набор файловых дескрипторов. один раз, поэтому нельзя изменить набор файловых дескрипторов, которые в настоящее время опрашиваются.
[Конечно, если вы передадите дескриптор файла, созданныйepoll_create
в poll()/select()
, модификации этого файлового дескриптора будут отслеживаться как epoll_wait
.]
Других решений пока нет …