Vitsliputsli, то что описываете вы - я написал сразу. демон + очередь, и сказал что этого должно хватить, и что по стабильности и скорости это решение не проиграет своему велосипеду ввиде пхп манагера процессов - как хотел автор.
Andrew Boeing, общая о чем? заходите в код чата на фронте и вместо просто отображения сообщения в окне пишете разбор того что вам прилетело - сообщение или команда. на стороне фронта манагера пишете возможность отправки команды. если у вас сложности с этим - то PHP для чайников, JS для чайников. Потому что знаний данных в них хватит что бы это реализовать.
Расширить чат, что бы можно было отправлять не только сообщения, но и управляющие команды, типа {command:'redirect', to: 'url'}. На стороне чата ловить их - и исполнять. Не?
Vitsliputsli, а какая разница в том что вы в своем манагере процессоров запустите 20 процессов изначально, или в супервизоре пропишете 20 демонов которые будут смотреть в очередь? разница только в том что надо будет самому написать свой манагер процессов на каком нибудь swoole. Когда я года полтора назад с ним возился, segmentation fault я ловил запросто, а в octane который его использовал - писали честно на свой страх и риск. Не вопрос - у меня руки кривые, а с тех пор там все пофиксили - но по факту я думаю будет куча сложностей.
Манагер процессов нужен что бы получать задачу, создавать воркер - отправлять туда на исполнение и ловить оттуда отлуп успешного/неуспешного выполнения. Если мы используем прослойку для общения между не связанными между собой процессами на php - то о каких потоках которые собирается запускать автор идет речь? В качестве прослойки берем тот же rabbitmq - и вперед.
Vitsliputsli, у меня нет претензий к пхп. претензии будут к попытке написать манагер процессов на пхп. это несколько разные вещи.
Соответственно те же проблемы будут и с брокером очередей, воркер один, и время работы будет очень большим.
И можете продолжить - ровно те же проблемы будут с манагером процессов. Потому что через неделю после того как вы напишите манагер процессов без ограничения спавна процессов - вы либо сами себе по шапке дадите, либо кто либо еще прибежит - и у вас будут лимиты. Собственно далеко ходить не надо php-fpm ровно такой Process Manager, ровно с лимитам. А разницы между тем что бы в манагере процессов мониторить количество воркеров, либо в каком нибудь супервизоре количество менять - я не вижу. если вы видите, то хотелось бы услышать
вы можете запускать внешний скрипт в бэкграунде - делов то.
но по факту все что вы тут расписали - решается очередью. сидит демон и мониторит очередь на наличие задач - получил обрабатывает. не получил - сидит ждет. профит по сравнению с чем? с вашей реализацией манагера потоков на php? ну при всем уважении к вам и пхп по стабильности я поставлю на какой нибудь rabbitmq, да и по скорости тоже на него.
vadikrudnov, очереди выигрывают у крона здесь только более гибкой настройкой количества одновременных обработок.
Если вам нужно прямое управление процессами - нужен манагер процессов. А куда идти за ним - я уже сказал.
В вашем случае приостановка задачи должна решаться через что то - базу данных, какую нибудь ключ-значение, или еще чего, что он должен мониторить что бы получить сообщение о том что ему надо сдохнуть.
Ну еще как вариант - это прикапывать к каждой задачи getmypid и банальным kill'ом сносить
vadikrudnov, если вы видете что данные изменились - вы тупо сворачиваете работу, следующий крон или следующая попытка обработки - начнет сначала. можно дергать не каждую обработку - а каждую десятую.
ну если не устраивает - говорю идете в swoole или еще чего, и пишете свой манагер процессов. ну или - бросаете пхп и идете в язык который более подходит к таким задачам. но я бы искренне порекомендовал первый вариант
vadikrudnov,
1. ну решение в лоб простое - у вас должна быть таблица задач, где лежат поставленные задачи пользователями с фильтрами, и при обработке этой задачи эпизодически опрашивать изменилась ли запись с задачей. правда решать такое через крон, такое себе - может лучше очереди?
2. ну можно полезть в какой нибудь swoole, roadrunner или еще чего и мутить там - но мне кажется вы не сможете.
vadikrudnov, ну еще раз задача не понятна - но вполне возможно что достаточно проверять при выполнении проверки - изменился ли статус у данных, если нет - не проверять. или после проверки - если статус изменился - не вносить изменения.
