Похоже, что MarkR и zackthehack уже полностью ответили на этот вопрос, но я хотел бы добавить, что Nginx является примером модели наследования сокетов прослушивания.
Implementation of HTTP Auth Server Round-Robin and
Memory Caching for NGINX Email Proxy
June 6, 2007
Md. Mansoor Peerbhoy <mansoor@zimbra.com>
...
Поток рабочего процесса NGINX
После того, как основной процесс NGINX читает файл конфигурации и разветвляется
в настроенное количество рабочих процессов, каждый рабочий процесс
входит в цикл, где он ожидает каких-либо событий на его
набор розеток.
Каждый рабочий процесс начинается только с прослушивающих сокетов,
так как пока нет доступных соединений. Поэтому событие
набор дескрипторов для каждого рабочего процесса начинается только с
прослушивающие розетки.
(ПРИМЕЧАНИЕ) NGINX можно настроить для использования любого из нескольких событий
механизмы опроса:
AIO / devpoll / Epoll / eventpoll / Kqueue / опрос / rtsig / выбрать
Когда соединение приходит на любой из сокетов прослушивания
(POP3 / IMAP / SMTP), каждый рабочий процесс выходит из своего опроса событий,
поскольку каждый рабочий процесс NGINX наследует слушающий сокет. Затем,
каждый рабочий процесс NGINX будет пытаться получить глобальный мьютекс.
Один из рабочих процессов получит блокировку, тогда как
другие вернутся к соответствующим циклам опроса событий.
Тем временем рабочий процесс, получивший глобальный мьютекс, будет
изучить запущенные события и создаст необходимую очередь работ
запросы на каждое событие, которое было инициировано. Событие соответствует
один дескриптор сокета из набора дескрипторов, которые
рабочий наблюдал за событиями от.
Если вызванное событие соответствует новому входящему соединению,
NGINX принимает соединение от слушающего сокета. Затем это
связывает контекстную структуру данных с дескриптором файла. это
контекст содержит информацию о соединении (будь то
POP3 / IMAP / SMTP, аутентифицирован ли пользователь и т. Д.). Затем,
этот вновь созданный сокет добавляется в набор дескрипторов событий
для этого рабочего процесса.
Рабочий теперь отказывается от мьютекса (что означает, что любые события
который прибыл на других работников может продолжаться), и начинается обработка
каждый запрос, который был ранее поставлен в очередь. Каждый запрос соответствует
событие, которое было сигнализировано. Из каждого дескриптора сокета, который был
сигнализированный рабочий процесс извлекает соответствующий контекст
структура данных, которая ранее была связана с этим дескриптором, и
затем вызывает соответствующие функции обратного вызова, которые выполняют
действия, основанные на состоянии этой связи. Например, в случае
недавно установленного соединения IMAP, первое, что NGINX
нужно написать стандартное приветственное сообщение IMAP на
подключенный разъем (* OK IMAP4 готов).
Постепенно каждый рабочий процесс завершает обработку рабочей очереди.
запись для каждого ожидающего события и возвращается к его событию
Цикл опроса. Как только любое соединение установлено с клиентом,
события обычно более быстрые, так как всякий раз, когда подключен сокет
готов к чтению, событие чтения запущено, и
должно быть предпринято соответствующее действие.