Привет. Вопрос сугубо теоретический. Дошли руки вчитаться в то, как именно

nginx работает под капотом. За счёт чего именно он такой быстрый и всё такое.
event-based, без использования потоков выше необходимого, non-blocking - это всё понятно, вопросов нет.
То, что nginx просто так не ждёт ни сеть, ни disk i/o - тоже понятно и красиво.

Что мне пока непонятно, так это следущее: всё, что можно перекинуть на ОС и просто ждать ивентов (сеть/сокеты, диск) - ок, nginx скидывает на ОС и просто ждёт ивентов о готовности.
Но все равно же остается кусок работы, который, кроме nginx worker'a, никто сделать не может: принять посмотреть на сам по себе HTTP-запрос, распарсить его параметры, определить логику дальнейшей обработки.
Получается, этот кусок работы worker всё же выполняет синхронно, и ставка делается на то, что это настолько малый объём работы, что он всегда выполняется практически моментально?

Или я пока не понимаю, каким образом при условии одного потока обеспечивается эта "асинхронность".

ну смотри ```посмотреть на сам по себе HTTP-запрос, распарсить его параметры, определить логику дальнейшей обработки.``` это же происходит как раз когда есть евент когда пакет доходит например до TCP (как компонента ядра), он его парсит и там в колонке destination port узнает порт приложения которому это отправить, потом ищет в системе сокет который забиндился на этот порт, и все эти данные тупо вливает в него, и тут активируется nginx и начинает с ними работать

> это же происходит как раз когда есть евент Тут не спорю. > когда пакет доходит .. и тут активируется nginx и начинает с ними работать Либо я не понял мысль, либо мой вопрос совсем не об этом. Мой вопрос именно о том, правильно ли я понял, что (и как) происходит на этапе "... и тут активируется nginx и начинает с ними работать" Получается, что, несмотря на всю логику с ивентами и реагированием на них - вся непосредственная обработка запроса самим worker'ом (уже полностью считанного/полученного с сокета) выполняется worker'ом синхронно и в один поток. > ... и ставка делается на то, что это настолько малый объём работы, что он всегда выполняется практически моментально

про «активацию nginx» у любого процесса есть состояние, S,R,Z и т д так вот, абстрагируясь от nginx, у тебя есть приложение, простейший сервер, его задача принять и обработать сетевой пакет, например как тут: #!/usr/bin/env python # -*- coding: utf-8 -*- import socket sock = socket.socket() sock.bind(('', 9090)) sock.listen(1) conn, addr = sock.accept() print 'connected:', addr while True: data = conn.recv(1024) if not data: break conn.send(data.upper()) conn.close() вот когда ты это запустил, в системе благодаря sock.bind будет создан сокет файл (которому tcp потом будет слать данные) и приложение будет в состоянии S как только в этот сокет придут данные (которые прислал TCP), приложение изменит свое состояние на R, и приступит к обработке данных, так вот, как оно их будет обрабатывать, в отдельном потоке или как это уже дело самого приложения и в целом «активация» и обработка тут немного в разном контексте выходит

> как только в этот сокет придут данные (которые прислал TCP), приложение изменит свое состояние на R, и приступит к обработке данных, так вот, как оно их будет обрабатывать, в отдельном потоке или как это уже дело самого приложения Вот, мой вопрос исключительно об этом. Меня интересует именно момент, когда worker уже успешно получил несколько наборов данных с разных сокетов (допустим, каким-то чудом это произошло практически одновременно), и дальше worker, переходя в состояние R, начинает обрабатывать внутри себя эти запросы... синхронно один за другим (?).