Да зачем, если тема не особо интересна, за полчаса можно рабочий пример написать, но полчаса жалко тратить, чтобы только победить в споре

Потому что это убьет скорость. Ваш этот процесс будет баттлнеком, потому что сисколы рид врайт это большая часть нагрузки веб сервера у которого экшены занимают околонулевое время.

Единственный вариант если нужно >100к rps, это делать рид врайты в каждом воркере самостоятельно

например, нам больше 100к рпс не нужно
но нужно быстрее чем сейчас

CGI:
Нам пришел запрос, мы запустили процесс, получили его результат и процесс закрылся.
Плюсы:
Изолированность (вы не сможете без специальных телодвижений попасть в соседний процесс. Гарантируется системой)
Минусы:
Медленно (Стоимость поднятия процесса ОЧЕНЬ дорогая. Да еще к тому-же и поднимать интерпретатор Перла, компилить код и т.д.)

Daemon (single process, single thread):
Вы запустили процесс, подготовились, приняли запрос по сокету, отдали ответ, подготовились к другому запросу)
Плюсы:
Не надо каждый раз запускать процесс.
Минусы:
Надо уметь чистить за собой и если вдруг что-то случиться у вас может накапливаться ошибка из-за побитой памяти от предыдущего запроса

Daemon (single process, multiple thread):
Вы запустили процесс, в нем запустили кучу потоков и в каждом из них получаете запросы и обрабатываете их)
Плюсы:
Потоки легковесны (относительно процессов), экономится память (так как экземпляр того-же интерпретатора один раз загружен в память).
Минусы:
Падение одного потока может привести к порче всего процесса.

Daemon(multiple process, single thread):
Вы запустили столько процссов сколько хотите, в кажом из них по одному потоку:
Плюсы:
Процессы независимы друг от друга. Падение одного не уронит другой.
Минусы:
Больший расход памяти, больше необходимо времени на инвалидацию кешей, если они есть и т.д.

Стоп вы меня запутали. Это же листен юникс сокет, там можно сделать нормально.

Тут, на самом деле, проще один раз архитектурно сделать правильно и потом условные адаптеры менять. А архитектурно сейчас лучше всего делать префорки и множественный баинд на сокет. В каждом форке - асинхронный эвент луп.

Я тут гдето вычитал что там больше одного баинда на сокет не сделаешь.

Больше и не нужно

Типа в форке они не будут мультиплицироваться.

Bind duplicate модель будет работать

т.е. не один один сокет и много воркеров, а много воркеров и один сокет. Я еще больше запутался )

Один сокет и много асинк воркеров. Быстрее пока никто ничего не придумал

Проблема в том что при скоростях 100к rps разница врядли будет ощутима

ну дак так сейчас с юниевентом можно?

Да.

https://metacpan.org/dist/UniEvent-HTTP-Manager/view/lib/UniEvent/HTTP/Manager.pod

Вот это все сделает за вас. Вам надо будет только вставить свой код в $mgr->request_callback

Спасибо большое, так понятно.

Unievent поддерживает юникс сокеты, но unievent-http из коробки щас нет.

а  можно тогда все таки пример как приложение, которое наружу торчит как plack, запустить вот так с несколькими воркерами и чтобы наружу оно торчало сокетом, который можно отдать нгинх и фастцги, который можно отдать апачевскому mod_fastcgi?

потому что я уже пол часа смотрю в исходники Plack::Handler::UniEvent::HTTP и не понимаю как