А в чём проблема сделать два связанных запроса? Открываем транзакцию и делаем. Или, если данные запросов куда то нужно пробрасывать, скажем, в мастер-поток, так как тред по каким то причинам этого делать не может, то можно для этого сгородить специальную структуру (буфер).
Никакого ада нет, libevent и компания вам в помощь. В конце концов, можно изобрести велосипед (даже с круглыми колёсами) и без него, но не так элегантно и *троллейбус.jpg*. Опять же, зависит от конкретной задачи, я бы не стал так однозначно утверждать, что правильно, а что нет.
[оффтопик] nodejs же как то работает, и ничего: там вам и асинхронность, и коллбек-хэлл ада нет никакого.
Помните хороший фильм, про бочку спирта в реке и про «это у тебя в уме, а у меня в бочке»? Вот так и тут: у вас «на практике» 10, а у меня на практике 4.6, с дефолтными настройками ядра на CentOS, которая ставилась по принципу «далее->далее->далее->ОК». ЧЯДНТ?
Конечно же нет, я тут просто новые баззворды осваиваю.
практически все статистические расчеты есть — обработка одного большого массива данных.
Про map-reduce вы, видимо, слышали, потому, это утверждение говорит лишь о том, о чём говорит: да, большое количество данных, но ведь и обработать их можно (относительно) без проблем. И на PHP такие вещи тоже можно писать, но не подумайте, я не агитирую за велосипеды и готов даже носить футболку с лого «Hadoop». Просто задачи бывают разных масштабов.
то же самое можно сказать и про морфологический разбор. Да и в онлайне он точно не нужен.
Правда? Почитайте про phpmorpfy, а лучше про его родителя pymorphy, где и кем они могут применяться. Почитайте про SEO (тут полёт фанзации по автогенерации слов\текстов неограничен), почитайте про корпусную лингвистику, про вольфрам-альфа, да хотя бы он-лайн переводчики. Веб — это давно не только сайтики с котятками, но и довольно серьёзные сервисы специфической направленности, и внутри у них может твориться много магии.
Поо большие наборы данных я не загибал, а обрабатывал. И причин, почему ваш foreach упал, может быть множество, начиная от общего говнокода и заканчивая неправильным подходом к построению системы.
так что переходим к семафорам? расскажешь, как на практике надо использовать семафоры?
Не уповайте на задежрки IO, есть куча задач, где длительный процесс их обработки нивелирует какие либо значимые задержки (загрузить данные в память и далее с ними работать), примеры таких задач я привёл. К тому же, многопоточная хитектура часто нужна про соображениям дизайна системы: вы таки будете писать сокет-сервер в один поток\процесс? Или применение принципов map-reduce в рамках одной машины, когда памяти не хватает, чтобы обработать весь массив данных, используя, скажем, сложную сортировку или выборку по какому то параметру?
Да, и чего вы решили, что если многотредовый — то обязательно синхронный? Треды могут вообще не знать ничего о внешнем мире и соседях, делать лишь свою часть задачи, они могут быть инициализированы заранее в виде пула, как делает множество другого ПО. И про прожорливость тредов вы неправду пишете, поток pthreads жрёт ~4.6 Мб, но никак не 10.
В дополнение, в многопоточном режиме данные можно сохранять в разные таблицы, и потом их мерджить (если это одна задача), мне знаком проект, где используются даже разные БД на свой пул форков. А уж возможности БД в виде отложенной записи, или синхронизация через кеши в памяти ещё сильнее ослабляют зависимость от медленного IO.
Полагаю, что вопрос аргументации, что вопрос про задачи не раскрыт, не раскрыт.
Я не говорил «установить», я говорил «задействовать» расширение Stream, подразумевая лишь его использование, а не установку или что то ещё.
Да, под виндой это не работает, так как основано на чисто никсовых системах (System V IPC, etc), которые, по понятным причинам, на винду портировать несколько… затруднительно. На Windows не акцентировал внимание в заметке, так как уже давно под ней ничего не пишу, да и абсолютное большинство PHP-программистов не используют WIndows в produсtion, потому, я полагал, что всё перечисленное в заметке будет по-умолчанию применяться в *.nix и под него же адаптироваться.
Однако, оба пункта отлично работают на *nix, и серьёзные вещи с использованием этих подходов можно писать. В догонку о proc_open, цитата из доки по stream_select: «Use of stream_select() on file descriptors returned by proc_open() will fail and return FALSE under Windows.»
Сществует множество стандартных потоков, которые имеют константные номера файловых дескрипторов (как ответили ниже), потому, никакой магии нет (документация на php.net). Обратите внимание на порядок закрытия\открытия стандартных потоков, имена переменных не важны, т.е, если вы хотите закрыть все три потока, а потом переоткрыть их, то открывайте в порядке возрастания их номеров (STDIN, STDOUT, STDERR), так как PHP автоматически назначает эти потоки, и явно указать, что вы сейчас открываете возможности нет. Это не касается зарезервированных потоков-обёрток типа «php://stdout».
Я использовал все приведённые в статье способы в виде готовых, рабочих решений, кроме pthreads — с ним я только писал хеллоуВорлды и пускал скупую слезу восхищения.
сигналы — в простейших системах типа «стартуем N процессов и откуда то ими рулим», или для синхронизации;
сокеты — для сервера\клиентов очереди сообщений, велосипедостроения типа селениума, коммуникации с питон-скриптами, да много где ещё;
шаред мемори и семафоры — в проектах для работы с внешними сервисами по API, когда требовалась синхронизация по определённым критериями, так как API, так сказать, «непотокобезопастный», и не требовалось активного обмена данными между потоками и их раскидыванием по разным машинам, а так же по работе с ffmpeg;
«извращения» — в молодые зелёные годы в поисках решений по сабжу заметки :) (вероятно, информация об описанных мною проблемах могла стать неактуальной)
Где то между всем этим проскакивал и libevent.
Это всё, что касается велосипедостроения, но, иногда в силу разных причин, нет возможности использовать какие то готовые решения, потому, пришлось осваивать и это.
Про файлики я не всерьёз, но и там можно сделать ход конём с помощью функций stream_* и ловить кайф синхронизации данных :)
Примеры, к сожалению, противоречат идеологии заметки, но, я подумаю :)
По поводу proc_open: это довольно неудобное решение (в сравнении с остальными), к тому же, одним proc_open вы не обойдётесь, придётся задействовать ещё и расширение Stream, а так же файловые функции для чтения\записи (или их аналоги из stream_*), перенаправления вывода, что при разработке чего то дальше приветмира оборачивается хаосом в коде, под всё это придётся писать обёртки и собирать в итоге под каким то удобоваримом интерфейсом. Ещё у этого решения есть проблемы с блокирующимся pipe-ами, с кодировкой что то было, на Windows (хотя это малозначимая проблема в 99% случаев) вообще можно словить цирк и феерию с ограничениями размера буферов. С popen припоминаю проблемы при chroot, при чтении бинарных данных.
Короче говоря, это работающий метод, но я бы крайне не рекомендовал его использование, в особенности, когда есть более приемлимые решения, лучше уж в файлики писать :)
Я уже отвечал на подобные вопросы, и в заметке об этом сказано, но всё же повторюсь: целью было рассмотреть IPC лишь в контексте PHP, и не готовый софт, а сами принципы\подходы (и их реализации в языке), а то, о чём вы пишете, хоть и работает с ним, но область применения и возможности далеко не ограничиваются одним PHP. К тому же, эти решения гуглятся довольно быстро, а уж в документации и примерах недостатка нет (Кстати, о сигналах тоже вагон информации, даже на php.net).
Собственно, постигать дзен типа различий в IO и тонкостях каждого подхода, читателю следует самому, так как раскрытие таких деталей в статье потянет за собой ещё и описание решений, которые позволяют обойти те или иные ограничения (читай libev* и co), а тут уже полёт фантазии не ограничен.
О тех же 0mq и gearman`ах многие хотя бы слышали, а вот о таких, казалось бы, базовых вещах — нет. Потому, вы верно заметили — это почва для размышлений, причём, рассчитанная на более-менее опытных пользователей, которая бы как то систематизировала их представления о вариантах реализации IPC в PHP.
Магия в неявном создании переменной, хранящей объект класса, такое нововведение некорректно обрабатывается, предполагаю, потому, что pthreads использует некоторые… неоднозначные вещи в коде, и потому, автор мог не учесть всех, нюансов zend'а. Ответ следует искать в работе менеджера памяти и сборщика мусора, ведь, в таком случае, после завершения вызова, объект уже как бы «бесхозный». К тому же, насколько мне известно, автор активно работает с версией 5.3, потому, мог не уследить за всеми тонкостями новых версий
Вы башорг парсить будете в один поток, или в несколько? А если не башорг, а уютненький фейсбучек? За рафинированными примерами можете сходить на гитхаб к автору pthreads, за нерафинированными — сесть и подумать, какие задачи в вебе могут быть решены не в один поток. Задачи, кстати, могут быть не только сайтописательскими, а и носить прикладной характер, скажем, морфологическая обработка неких текстов или иных больших массивов данных, генерация статистической информации и так далее.
Другое дело, что PHP со своими форками\потоками, как известно каждому бородатому С-шнику, не для каждой задачи подходит, но ведь речь сейчас не об этом, верно? :)
Я писал, что если неблокирующий IO НЕ нужен, то можно задействовать flock, да и не рассматриваю Windows, как платформу для разработки.
«Мы выживали как могли» (С) :)
[оффтопик] nodejs же как то работает, и ничего: там вам и асинхронность, и
коллбек-хэллада нет никакого.Конечно же нет, я тут просто новые баззворды осваиваю.
Про map-reduce вы, видимо, слышали, потому, это утверждение говорит лишь о том, о чём говорит: да, большое количество данных, но ведь и обработать их можно (относительно) без проблем. И на PHP такие вещи тоже можно писать, но не подумайте, я не агитирую за велосипеды и готов даже носить футболку с лого «Hadoop». Просто задачи бывают разных масштабов.
Правда? Почитайте про phpmorpfy, а лучше про его родителя pymorphy, где и кем они могут применяться. Почитайте про SEO (тут полёт фанзации по автогенерации слов\текстов неограничен), почитайте про корпусную лингвистику, про вольфрам-альфа, да хотя бы он-лайн переводчики. Веб — это давно не только сайтики с котятками, но и довольно серьёзные сервисы специфической направленности, и внутри у них может твориться много магии.
Поо большие наборы данных я не загибал, а обрабатывал. И причин, почему ваш foreach упал, может быть множество, начиная от общего говнокода и заканчивая неправильным подходом к построению системы.
NO.
Да, и чего вы решили, что если многотредовый — то обязательно синхронный? Треды могут вообще не знать ничего о внешнем мире и соседях, делать лишь свою часть задачи, они могут быть инициализированы заранее в виде пула, как делает множество другого ПО. И про прожорливость тредов вы неправду пишете, поток pthreads жрёт ~4.6 Мб, но никак не 10.
В дополнение, в многопоточном режиме данные можно сохранять в разные таблицы, и потом их мерджить (если это одна задача), мне знаком проект, где используются даже разные БД на свой пул форков. А уж возможности БД в виде отложенной записи, или синхронизация через кеши в памяти ещё сильнее ослабляют зависимость от медленного IO.
Полагаю, что вопрос аргументации, что вопрос про задачи не раскрыт, не раскрыт.
Да, под виндой это не работает, так как основано на чисто никсовых системах (System V IPC, etc), которые, по понятным причинам, на винду портировать несколько… затруднительно. На Windows не акцентировал внимание в заметке, так как уже давно под ней ничего не пишу, да и абсолютное большинство PHP-программистов не используют WIndows в produсtion, потому, я полагал, что всё перечисленное в заметке будет по-умолчанию применяться в *.nix и под него же адаптироваться.
Однако, оба пункта отлично работают на *nix, и серьёзные вещи с использованием этих подходов можно писать. В догонку о proc_open, цитата из доки по stream_select: «Use of stream_select() on file descriptors returned by proc_open() will fail and return FALSE under Windows.»
сигналы — в простейших системах типа «стартуем N процессов и откуда то ими рулим», или для синхронизации;
сокеты — для сервера\клиентов очереди сообщений, велосипедостроения типа селениума, коммуникации с питон-скриптами, да много где ещё;
шаред мемори и семафоры — в проектах для работы с внешними сервисами по API, когда требовалась синхронизация по определённым критериями, так как API, так сказать, «непотокобезопастный», и не требовалось активного обмена данными между потоками и их раскидыванием по разным машинам, а так же по работе с ffmpeg;
«извращения» — в молодые зелёные годы в поисках решений по сабжу заметки :) (вероятно, информация об описанных мною проблемах могла стать неактуальной)
Где то между всем этим проскакивал и libevent.
Это всё, что касается велосипедостроения, но, иногда в силу разных причин, нет возможности использовать какие то готовые решения, потому, пришлось осваивать и это.
Про файлики я не всерьёз, но и там можно сделать ход конём с помощью функций stream_* и ловить кайф синхронизации данных :)
По поводу proc_open: это довольно неудобное решение (в сравнении с остальными), к тому же, одним proc_open вы не обойдётесь, придётся задействовать ещё и расширение Stream, а так же файловые функции для чтения\записи (или их аналоги из stream_*), перенаправления вывода, что при разработке чего то дальше приветмира оборачивается хаосом в коде, под всё это придётся писать обёртки и собирать в итоге под каким то удобоваримом интерфейсом. Ещё у этого решения есть проблемы с блокирующимся pipe-ами, с кодировкой что то было, на Windows (хотя это малозначимая проблема в 99% случаев) вообще можно словить цирк и феерию с ограничениями размера буферов. С popen припоминаю проблемы при chroot, при чтении бинарных данных.
Короче говоря, это работающий метод, но я бы крайне не рекомендовал его использование, в особенности, когда есть более приемлимые решения, лучше уж в файлики писать :)
Собственно, постигать дзен типа различий в IO и тонкостях каждого подхода, читателю следует самому, так как раскрытие таких деталей в статье потянет за собой ещё и описание решений, которые позволяют обойти те или иные ограничения (читай libev* и co), а тут уже полёт фантазии не ограничен.
О тех же 0mq и gearman`ах многие хотя бы слышали, а вот о таких, казалось бы, базовых вещах — нет. Потому, вы верно заметили — это почва для размышлений, причём, рассчитанная на более-менее опытных пользователей, которая бы как то систематизировала их представления о вариантах реализации IPC в PHP.
замените на
Другое дело, что PHP со своими форками\потоками, как известно каждому бородатому С-шнику, не для каждой задачи подходит, но ведь речь сейчас не об этом, верно? :)
И о каких запросах идёт речь?