xmoonlight: пока нет, все не дойдут руки допилить вариант который можно показывать людям (в проекте сейчас используется написанный на скорую руку вариант), может на следующей неделе... На данный момент поделка эта умеет только генерировать процессы из итератора с возможностью отслеживания сколько одновременно процессов может быть запущено (в неблокируемом режиме, через proc_open). В планах сделать так же возможность не убивать воркеры и организовать общение с мастером через пайпы, что в принципе не сложно, но на это нужно время. Последнее мне нужно для того что бы сделать свой паралелизатор для бихата, ибо... при подходе с запуском воркеров на каждый чих, у меня половина времени выполнения одного воркера будет занимать его бутстрапинг.
xmoonlight: клиента по проекту, в рамках которого мне понадобилось написать менеджер процессов что бы распаралелить обработку одной простенькой штуки. Менеджер процессов давно уже просят в ишусах симфони, так что появилось желание законтрибьютить.....
xmoonlight: для контраста, я имел возможность баловаться со всеми перечисленными способами IPC, сейчас вот пилю медленно но верно менеджер процессов для symfony/process под свои нужды на пайпах. На пайпах Карл (не удержался, клиента зовут так).
xmoonlight: да ладно вам, руки кривые, зачем специально повышать риски? Все банально упирается в юз кейсы которые мы хотим решить. Сокеты решают 98% задачь затрагивающих IPC эффективно как с точки зрения производительности, так и с точки зрения трудозатрат. Оставшиеся 2% - разработчики таких систем думаю не будут спрашивать на тостере что юзать для IPC.
xmoonlight: зависит от того насколько интенсивный обмен данными идет. По сути использование сокетов на лупбэк интерфейсе не сильно медленнее шаред мемори, сетевой стэк не задействуется.
Шаред мемори круто если у вас есть пачка данных, которые редко меняются и которые надо часто читать. Вот тогда это идеальный кейс для организации IPC. Если же данные меняются часто или вам надо обмен сообщениями организовать, то сокеты (особенно если сервер пишите не вы, а скажем, мы берем готовый zeromq) намного более рационально использовать.
andreyqin: сори, я подумал что вы просто пробрасываете на внешку встроенный сервер. Тунелирование чуть по другому работает.
оно использует сервис localtunnel.me для того что бы привязать ваш IP текущий к какому-то домену, который знаете только вы и который доступен только пока запущен browsersync. Ссылка будет доступна третьей стороне, но я сомневаюсь что кому-то будет интересно трекать именно вас. Тем более что с динамическим IP при повтором подключении в сеть у вас будет уже другой адрес.
Если вы не хотите палиться, то есть еще вариант - предоставить клиенту SSH тунель и тогда он будет заходить на сайт как буд-то бы тот развернут у клиента на машине.
andreyqin: она доступна всем кому вы ее скините. Ну еще есть вероятность что ваш комп регулярно сканируется на предмет открытых портов... но это сами понимаете.
xmoonlight: в реальности методов не много:
- пайпы (unix only, на шиндовс боль и унижение)
- сокеты (работает всегда)
- шаред мемори (эффективно, но сложно и можно напороться на кучу грабель)
Все остальное - слишком специфично и подходит только в конкретных случаях. Так что имхо, если нужна кросплатформенность, то только сокеты.
iKapex: суть в том что внутри getDoctrine вызывается get('doctrine'), и что-то там не так, может внутри get метода идет ошибка на чем-то в духе $this->container->get('doctrine') - контейнер не проинициализирован или занулен... мало ли.
Horoko: ну... не совсем так, но суть такая. Если вам надо узнать координаты точки в массиве - считаете по формуле. Обратное тоже работает - можно из координат получить индекс по которому находится значение глубины.
Horoko:
по идее координата каждой точки определяется как
x=index % width
y=index/width
Линейные массивы занимают меньше места в памяти (не нужно хранить еще указатели на ряды/колонки) ну и меньше кэш-мисов. Потому в машинной графике чаще делают именно так.
