HTTP/2

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

MiksIr написал(а):

А как иначе мультиплекс писать? По сути в мультиплексе должен быть один ожидающий цикл, в котором и активность входящих соединений и ожидание ответа базы.

Нажмите для раскрытия...

иначе чем что? господа, не могли бы вы писать логически связанные фразы?

асинхронность именно так и пишется - ожидается активность входящих соединений и ответы базы.
в чем вопрос-то?

В том, можно ли в списки mysqli_poll запихнуть ресурсы созданные socket_create/socket_accept что бы принимать соединения и работать с сокетами.

grigori написал(а):

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

Нажмите для раскрытия...

Фатальный изьян там, видимо, в невозможности использовать mysqli ресурсы вместе с libevent? Это вопрос если что, сам не пробовал.

mysqli сам по себе в цикл не входит и не блокирует, с ним можно работать из цикла либивента

MiksIr написал(а):

В том, можно ли в списки mysqli_poll запихнуть ресурсы созданные socket_create/socket_accept что бы принимать соединения и работать с сокетами.

Нажмите для раскрытия...

а зачем работать с сокетами из mysqli_poll?

Да, но для этого нужно как-то добраться до tcp сокета, коим ресурс mysqli не является. Это и может быть проблемой. А может просто этот код появился раньше чем асинхронность в mysqli...

можно вынести mysql_poll в соседний поток, запускать mysql_poll с таймаутом 1 мс, дергать reap_async_query() не дожидаясь poll()
я бы сделал как угодно, но без парсинга протокола mysql на php

главная проблема этой архитектуры - затык в одно ядро проца, главный цикл должен быть как можно легче, чем он тяжелее - тем быстрее ляжет под нагрузкой,
но нет, они его еще обработкой бинарного протокола нагружают

Парсинг бинарных данных как раз не должен быть затратный. А ты предлагаешь как раз нагружать процессор постоянным вываливанием из poll-а и проверкой -а не поставил ли соседний поток задач на работу с базой. А соседний поток по работе с сетью тоже придется постоянно просыпать - что бы он проверял - нет ли ответных данных от базы. И это при том, что специально создан механизм переноса этого ожидания данных в ядро.
Затык то на ядро легко решается несколькими воркерами. Во многих случаях даже IPC между воркерами не нужен.

В случае с mysql есть как минимум libdrizzle, совместимая по протоколу с libmysql и умеющая работать асинхронно и встраиваться в event loop - вот, скажем, пример с libev. Впрочем, большинство протоколов недостаточно сложны, чтобы было затруднительно их реализовать в рамках event loop based-фреймворка - вон и в node.js, и в reactphp все сделано уже. Другое дело, что есть более удобные средства разработки, чем js/v8 и php/zend, - когда event loop скрыт внутри и не надо устраивать ад колбэков и нет проблем с обработкой ошибок, - но и на js и php это в принципе решается специализированными фреймворками.

Вообще большинство сетевых приложений io-bound, а вовсе не cpu-bound. С масштабированием по ядрам для веб-приложения обычно вообще не проблема - количество запросов, обрабатываемых за среднее время обработки одного запроса, значительно превышает количество ядер, так что прекрасно работает классическая схема master + workers. Если очень нужен IPC между воркерами - это решается классическими unix ipc средствами, при желании можно сделать и тредпул.

если он относительно незатратный - да, а ipc в виде сокетов тут не избежать

А для cpu bound задач сразу уместно говорить о масштабировании вычислений не только по ядрам, но и по серверам, а тут мы приходим к map-reduce как ни крути

мне кажется, расстояние между single-core и map-reduce довольно велико
а вообще, php для всего этого неудобен

А мне кажется не так уж велико. Если мы можем разделить задачу на отдельные сервисы, обменивающиеся данными, то в общем-то все равно, это пачка одноядерных машинок или пачка ядер. (Понятно, что на одной машинке можно избежать копирования данных, но это мелочи при cpu-bound). А если сама по себе неделимая задача уже не помещается в ядро - тут остается два варианта, либо мы можем выразить ее в терминах map-reduce и сделать таким образом делимой, либо все, приехали.

grigori написал(а):

можно вынести mysql_poll в соседний поток

Нажмите для раскрытия...

В какой поток? PHP еще не умеет стабильно потоки, и нестабильно научился совсем недавно (год назад).
А демону этому уже много лет.

можно реализовать как соседний процесс, а не поток, и получить сервисную архитектуру, и дальше по тексту

grigori написал(а):

можно реализовать как соседний процесс, а не поток, и получить сервисную архитектуру, и дальше по тексту

Нажмите для раскрытия...

А IPC процессов сделаем на сокетах, и процессу работающему с базой придется слушать сокеты, и опять мы на том же месте.

блокирующие вызовы не отжирают процессорное время

ну, да, при cpu bound нет никакого смысла разводить всю эту асинхронщину. Это вроде очевидно