[Перевод] Реализация epoll, часть 3
В предыдущих двух материалах (часть 1, часть 2) этой серии речь шла об общих вопросах работы epoll, и о том, как epoll получает уведомления о новых событиях от файловых дескрипторов, за которыми наблюдает. Здесь я расскажу о том, как epoll хранит уведомления о событиях, и о том, как эти уведомления получают приложения, работающие в пользовательском режиме.
Функция ep_poll_callback ()
Как уже было сказано, функция ep_insert() прикрепляет текущий экземпляр epoll к очереди ожидания файлового дескриптора, за которым осуществляется наблюдение, и регистрирует ep_poll_callback() в качестве функции возобновления работы процесса в соответствующей очереди. Как выглядит ep_poll_callback()? Узнать об этом можно, заглянув в строку 1002 файла fs/eventpoll.c (тут приведён лишь самый важный для нас код):
static int ep_poll_callback(wait_queue_t *wait, unsigned mode, int sync, void *key)
{
int pwake = 0;
unsigned long flags;
struct epitem *epi = ep_item_from_wait(wait);
struct eventpoll *ep = epi->ep;
Сначала ep_poll_callback() пытается получить структуру epitem, связанную с файловым дескриптором, который вызвал ep_poll_callback() с использованием ep_item_from_wait(). Вспомните о том, что раньше мы называли структуру eppoll_entry «связующим звеном», поэтому получение реального epitem выполняется путём выполнения простых операций с указателями:
static inline struct epitem *ep_item_from_wait(wait_queue_t *p)
{
return container_of(p, struct eppoll_entry, wait)->base;
}
После этого ep_poll_callback() блокирует структуру eventpoll:
spin_lock_irqsave(&ep->lock, flags);
Потом функция проверяет возникшее событие на предмет того, является ли оно именно тем событием, наблюдение за которым пользователь поручил epoll. Помните о том, что функция ep_insert() регистрирует коллбэк с маской событий, установленной в ~0U. У этого есть две причины. Первая — пользователь может часто менять состав отслеживаемых событий через epoll_ctl(), а перерегистрация коллбэка не особенно эффективна. Второе — не все файловые системы обращают внимание на маску события, поэтому использование масок — это не слишком надёжно.
if (key && !((unsigned long) key & epi->event.events))
goto out_unlock;
Теперь ep_poll_callback() проверяет, пытается ли экземпляр epoll передать сведения о событии в пользовательское пространство (с помощью epoll_wait() или epoll_pwait()). Если это так, то ep_poll_callback() прикрепляет текущую структуру epitem к односвязному списку, голова которого хранится в текущей структуре eventpoll:
if (unlikely(ep->ovflist != EP_UNACTIVE_PTR)) {
if (epi->next == EP_UNACTIVE_PTR) {
epi->next = ep->ovflist;
ep->ovflist = epi;
if (epi->ws) {
__pm_stay_awake(ep->ws);
}
}
goto out_unlock;
}
Так как мы удерживаем блокировку структуры eventpoll, то при выполнении этого кода, даже в SMP-окружении, не может возникнуть состояние гонок.
После этого ep_poll_callback() проверяет, находится ли уже текущая структура epitem в очереди готовых файловых дескрипторов. Это может произойти в том случае, если у программы пользователя не было возможности вызвать epoll_wait(). Если такой возможности и правда не было, то ep_poll_callback() добавит текущую структуру epitem в очередь готовых файловых дескрипторов, которая представлена членом rdllist структуры eventpoll.
if (!ep_is_linked(&epi->rdllink)) {
list_add_tail(&epi->rdllink, &ep->rdllist);
ep_pm_stay_awake_rcu(epi);
}
Далее, функция ep_poll_callback() вызывает процессы, ожидающие в очередях wq и poll_wait. Очередь wq используется самой реализацией epoll в том случае, когда пользователь запрашивает информацию о событиях с применением epoll_wait(), но время ожидания пока не истекло. А poll_wait используется epoll-реализацией операции poll() файловой системы. Помните о том, что за событиями файловых дескрипторов epoll тоже можно наблюдать!
if (waitqueue_active(&ep->wq))
wake_up_locked(&ep->wq);
if (waitqueue_active(&ep->poll_wait))
pwake++;
После этого функция ep_poll_callback() освобождает блокировку, которую она захватила ранее, и активирует poll_wait, очередь ожидания poll(). Обратите внимание на то, что мы не можем активировать очередь ожидания poll_wait во время удержания блокировки, так как существует возможность добавления файлового дескриптора epoll в его собственный список файловых дескрипторов, за которыми осуществляется наблюдение. Если сначала не освободить блокировку — это может привести к ситуации взаимной блокировки.
Член rdllink структуры eventpoll
В epoll используется очень простой способ хранения готовых файловых дескрипторов. Но, на всякий случай, я о нём расскажу. Речь идёт о члене rdllink структуры eventpoll, который является головой двусвязного списка. Узлы этого списка — это самостоятельные структуры epitem, у которых имеются произошедшие события.
Функции epoll_wait () и ep_poll ()
Расскажу о том, как epoll передаёт список файловых дескрипторов при вызове epoll_wait() программой пользователя. Функция epoll_wait() (файл fs/eventpoll.c, строка 1963) устроена очень просто. Она выполняет проверку на наличие ошибок, получает структуру eventpoll из поля private_data файлового дескриптора и вызывает ep_poll() для решения задачи по копированию событий в пользовательское пространство. В оставшейся части этого материала я уделю основное внимание именно ep_poll().
Объявление функции ep_poll() можно найти в строке 1588 файла fs/eventpoll.c. Вот фрагменты кода этой функции:
static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, int maxevents, long timeout)
{
int res = 0, eavail, timed_out = 0;
unsigned long flags;
long slack = 0;
wait_queue_t wait;
ktime_t expires, *to = NULL;
if (timeout > 0) {
struct timespec end_time = ep_set_mstimeout(timeout);
slack = select_estimate_accuracy(&end_time);
to = &expires;
*to = timespec_to_ktime(end_time);
} else if (timeout == 0) {
timed_out = 1;
spin_lock_irqsave(&ep->lock, flags);
goto check_events;
}
Легко заметить то, что данная функция использует различные подходы к работе в зависимости от того, блокирующим или неблокирующим должен быть вызов epoll_wait(). Если вызов является блокирующим (timeout > 0), то функция вычисляет end_time на основе предоставленного ей значения timeout. Если вызов должен быть неблокирующим (timeout == 0), то функция переходит прямо к блоку кода, соответствующего метке check_events:, о котором мы поговорим ниже.
Блокирующая версия
fetch_events:
spin_lock_irqsave(&ep->lock, flags);
if (!ep_events_available(ep)) {
init_waitqueue_entry(&wait, current);
__add_wait_queue_exclusive(&ep->wq, &wait);
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
if (ep_events_available(ep) || timed_out)
break;
if (signal_pending(current)) {
res = -EINTR;
break;
}
spin_unlock_irqrestore(&ep->lock, flags);
if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
timed_out = 1; /* resumed from sleep */
spin_lock_irqsave(&ep->lock, flags);
}
__remove_wait_queue(&ep->wq, &wait);
set_current_state(TASK_RUNNING);
}
Прежде чем в fetch_events: начнут выполняться какие-то действия, нужно захватить блокировку текущей структуры eventpoll. А иначе, если мы вызовем для проверки наличия новых событий ep_events_available(ep), у нас будут неприятности. Если новых событий нет, то функция добавит текущий процесс в очередь ожидания ep, о которой мы говорили выше. Затем функция установит состояние текущей задачи как TASK_INTERRUPTIBLE, освободит блокировку и сообщит планировщику о необходимости перепланировки, но при этом и установит таймер ядра для перепланировки текущего процесса по истечению заданного промежутка времени или в том случае, если он получит какой-нибудь сигнал.
После этого, когда процесс начинает выполняться (вне зависимости от того, что инициировало его выполнение: тайм-аут, сигнал, новое полученное событие), ep_poll() опять захватывает блокировку eventpoll, убирает себя из очереди ожидания wq, возвращает состояние задачи в значение TASK_RUNNING и проверяет, получила ли она что-нибудь интересное. Это делается в блоке check_events:.
Блок check_events:
Функция ep_poll(), всё ещё удерживая блокировку, проверяет, имеются ли некие события, о которых нужно сообщить. После этого она освобождает блокировку:
check_events:
eavail = ep_events_available(ep);
spin_unlock_irqrestore(&ep->lock, flags);
Если функция не обнаружила событий, и если не истёк тайм-аут, что может произойти в том случае, если функция была активирована преждевременно, она просто возвращается в fetch_events: и продолжает ждать. В противном случае функция возвращает значение res:
if (!res && eavail && !(res = ep_send_events(ep, events, maxevents)) && !timed_out)
goto fetch_events;
return res;
Неблокирующая версия
Неблокирующая версия функции (timeout == 0) очень проста. При её использовании сразу осуществляется переход к метке check_events:. Если событий на момент вызова функции не было, она не ждёт поступления новых событий.
Итоги
На этом мы завершаем третью часть цикла материалов о реализации epoll. В следующей части мы поговорим о том, как события копируются в пространство пользователя, и о том, как приходится поступать этой реализации epoll при использовании механизмов срабатывания по фронту и срабатывания по уровню.
Часто ли вам приходится, разбираясь с какой-нибудь проблемой, добираться до исходного кода используемых вами опенсорсных инструментов?
