Каково назначение и преимущества системного вызова epoll в Linux

Эй, ты, смотри сюда, а то сейчас про epoll расскажу так, что у тебя мозги встанут на место, а потом обратно перевернутся. Это же, блядь, главная магия в Линуксе для того, чтобы не сойти с ума, когда у тебя тысяча клиентов одновременно стучится в сокет.

Представь, что ты бармен в адской забегаловке. Старые методы — select и poll — это как если бы ты каждые пять секунд обходил всех посетителей и спрашивал: «Ну что, пиво долить? А тебе? А тебе?». Заебёшься же, сука, особенно если их сотни. Тратишь кучу времени на тех, кто ещё и пить не хочет.

А epoll — это умная система. Ты садишься на стул, а у тебя над барной стойкой висит табло, как в аэропорту. И загорается номерок только у того столика, где клиент реально машет пустым стаканом и орёт: «Налей уже, ёпта!». То есть ты реагируешь только на события, а не бегаешь как угорелый. Сложность O(1), детка, это когда время обработки не зависит от общего количества долбоёбов за столиками, а только от тех, кто реально готов к обслуживанию. Ни хуя себе эффективность!

Чем он так охуенен:

• Масштабируется как боженька: epoll_wait() возвращает тебе только тех, кто готов. 10 тысяч подключений, но данные пришли только от 50? Получишь 50 событий, а не будешь 10 тысяч дескрипторов перебирать. В отличие от тех убогих select/poll, где сложность O(N) и ты вынужден смотреть на всех, даже на спящих.
• Два режима, как на стиралке:
  • Level-triggered (LT, стоит по умолчанию): Табло горит, пока стакан пустой. Не прочитал все данные за раз — на следующей итерации epoll_wait() опять тебе этот дескриптор подсветит. Проще, но можно и проебаться с производительностью.
  • Edge-triggered (ET): Табло мигнёт один раз, когда стакан только что опустел. Дальше — твои проблемы. Если не вычитал всё сразу и не обработал, то больше уведомления не получишь, пока не придут новые данные. Режим для настоящих мужиков, требует чтобы код был без багов и читал до победного, но зато скорость — овердохуищная.
• Ядро — твой друг: Список отслеживаемых сокетов живёт в ядре, а не таскается туда-сюда при каждом вызове. Представь, что вместо того, чтобы каждый раз переписывать всю книгу гостей, ты просто делаешь в ней пометки. Экономия — пиздец.

Смотри, как это выглядит в коде (Python):

import select
import socket

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.setblocking(False)
server.bind(('0.0.0.0', 8080))
server.listen(128)

# Создаём объект epoll — наш волшебный пульт управления
epoll = select.epoll()
# Регистрируем серверный сокет: "Слушай, ядро, как только кто-то захочет подключиться (EPOLLIN) — дай знать!"
epoll.register(server.fileno(), select.EPOLLIN)

connections = {}

try:
    while True:
        # Сидим и ждём событий. Таймаут 1 секунда, чтобы не зависнуть нахуй.
        events = epoll.poll(1)
        for fd, event in events:
            # Если событие на серверном сокете — значит, новый клиент ломится
            if fd == server.fileno():
                client, addr = server.accept()
                client.setblocking(False)
                # Регистрируем нового клиента тоже на чтение
                epoll.register(client.fileno(), select.EPOLLIN)
                connections[client.fileno()] = client
            # Если событие на клиентском сокете — пора читать, что он нам написал
            elif event & select.EPOLLIN:
                client_socket = connections[fd]
                data = client_socket.recv(1024)
                if not data:
                    # Клиент отключился — вычёркиваем его из всех списков
                    epoll.unregister(fd)
                    client_socket.close()
                    del connections[fd]
finally:
    # Уборка после себя — святое дело
    epoll.close()
    server.close()

Вот и вся магия. Вместо цикла по всем сокетам ты получаешь от ядра готовый список тех, с кем уже можно работать. Красота, да? Главное — в режиме ET не проебаться и всё вычитывать до конца, а то клиент будет тебе данные слать, а ты будешь сидеть и удивляться: «И че это они все замолчали?».