Может ли epoll или kqueue обрабатывать асинхронное добавление файловых дескрипторов к себе

Если один поток (скажем, X) ожидает epoll_wait(), другой поток (скажем, Y) может вызвать epoll_ctl(), чтобы зарегистрировать интерес к файловому дескриптору 9. Может ли предыдущий вызов epoll_wait() в потоке X вернуть файловый дескриптор 9, добавленный потоком Y? Первоначальный вызов epoll_wait() ни разу не возвращался посередине.

Теперь я хочу сравнить это и задать соответствующие вопросы в отношении двух других вызовов опроса в операционных системах. poll() и kqueue

  1. Если ответ на приведенный выше вопрос верен, то есть ли способ добиться аналогичного поведения с системным вызовом poll()?
  2. Предположим, что epoll_ctl() является потокобезопасным, а поток X может безопасно вызывать epoll_ctl(), а вызов epoll_wait() возвращает информацию о том, готов ли файловый дескриптор 9 к вводу-выводу. Разделение функции объявления интереса к файловому дескриптору и функции ожидания делает эту функцию удивительной. Но люди часто говорят, что kqueue и epoll используются для одной и той же функциональности. Однако kqueue не имеет отдельной функции для объявления заинтересованности в получении обратной связи о событии для дескриптора. Кто-нибудь знает, как kqueue можно использовать так же, как epoll? epoll кажется лучшим потокобезопасным вариантом прямо сейчас, если он разрешает потокобезопасное «объявление интереса»

c++ multithreading sockets epoll kqueue
person Curious    schedule 02.01.2016    source источник
comment
С помощью kqueue вы можете заявить о заинтересованности без получения отзывов о событии, передав 0 в качестве параметра nevents. См., например, этот ответ   -  person Tsyvarev    schedule 02.01.2016

Ответы (1)


arrow_upward
3
arrow_downward

От человека epoll_wait:

Пока один поток заблокирован при вызове epoll_pwait(), другой поток может добавить файловый дескриптор к ожидаемому экземпляру epoll. Если новый файловый дескриптор будет готов, вызов epoll_wait() разблокируется.

Таким образом, epoll_wait наблюдает за добавленным файловым дескриптором во время ожидания.

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

[Конечно, если вы передадите файловый дескриптор, созданный epoll_create, в poll()/select(), изменения этого файлового дескриптора будут отслеживаться, как и в случае с epoll_wait.]

person Tsyvarev    schedule 02.01.2016
comment
Я не знал, что существует epoll_pwait. В чем разница между epoll_wait() и epoll_pwait()? - person Curious; 02.01.2016
comment
Хм, это похоже на опечатку на странице руководства: в одном предложении используются epoll_pwait и epoll_wait, хотя на самом деле это означает одну и ту же функцию. epoll_pwait отличается от epoll_wait тем, что дополнительно позволяет задать заданный сигнал во время выполнения. Смотрите man для более подробной информации. - person Tsyvarev; 02.01.2016
comment
epoll_pwait — это не опечатка, это вариант epoll_wait, который позволяет управлять безопасной обработкой сигналов. Подробнее читайте здесь. - person Myst; 01.05.2016
comment
@Myst: мне известно о существовании epoll_pwait. Опечатка использует эту функцию вместе с epoll_wait в цитируемом примечании: while one thread is blocked in ... *epoll_pwait*, ... it will cause the *epoll_wait* to unblock. При разных функциях эта заметка не имеет смысла. - person Tsyvarev; 03.05.2016