Собственно это скорее полутопик-полувопрос.
Я опишу схему, которая у меня получилась и попрошу у хабралюдей совета — насколько такая реализация имеет право на жизнь и что в ней стоит улучшить =)
Возможно кому то такая идея понравится и он возьмет ее на вооружение — я не против =)

Такая схема у меня используется в двух задачах, однако распишу все на примере одной.
Итак, у меня есть некоторый онлайн браузерный игровой проект. Задача стояла в том чтобы написать максимально быстродействующий чат, обладающий следующими свойствами:
— низкая нагрузка, создаваемая чатом на сервер;
— поддержка большого количества игроков;
— возможность работы как в непрерывном так и в обычном (рефреш) режимах;
— возможность работы у игроков за прокси-серверами.

Введение

ZendX_Console_Process_Unix позволяет разработчикам создавать объекты под видом процессов, и таким образом параллельно выполнять несколько задач. Из-за особенностей реализации на текущий момент эта возможность доступна только на *nix системах, таких как Linux, Solaris, Mac / OSX и другие в CLI или CGI режиме. Кроме того для работы этого компонента необходимы следующие модули: Shared Memory, Process Control и POSIX. Если одно из требований не выполняется, то будет брошено исключение.

Основы использования ZendX_Console_Process_Unix

ZendX_Console_Process_Unix это абстрактный класс, который должен быть расширен пользователем. В нем находится единственный абстрактный метод _run(), который должен описывать реализуемый алгоритм обработки тех или иных данных. Так же в классе определенны методы для проверки состояния процесса и обмена переменными между основным и дочерними процессами.

Метод _run(), а так же каждый метод вызванный внутри него будет выполняться в отдельном процессе. Любой другой метод, вызванный в вашем приложении будет выполняться в родительском процессе.

Методы setVariable () и getVariable () могут быть использованы для передачи переменных между родительским и дочерними процессами. Для наблюдения за статусом дочернего процесса следует вызывать внутри него метод _setAlive () через короткие промежутки времени, таким образом родительский процесс сможет получить информацию о состоянии дочернего процесса посредством вызова метода getLastAlive (). Чтобы получить PID дочернего процесса, родитель может вызвать getPid().

Разделяемая (shared) память является очень эффективным средством оптимизации за счет очень быстрого доступа (в 100 раз быстрее чем глобальная память). Однако, при неправильном использовании ее возможны конфликты банков, которые существенно замедляют быстродействие. В данной статье пойдет речь о том, как эти конфликты возникают, и как их избежать.

Сейчас довольно популярно использование Comet-технологии, «когда при которой постоянное HTTP-соединение позволяет веб-серверу отправлять (push) данные браузеру, без дополнительного запроса со стороны браузера», согласно википедии.
Реализаций этой технологии есть много разных, но я сейчас хочу остановиться на одной из них, которая называется Long Polling. В статье я разберу, что это такое и с чем его едят.
Ну а тем, кто знает, что это, возможно, будетинтересно посмотреть на реализацию, которая не использует сторонний софт для своей работы — только PHP. Зачем это нужно, если есть специальные comet-сервера, которые выдержат гораздо более высокие нагрузки, чем скрипт на PHP? Это может пригодиться, если нужно сделать небольшой проект без высоких нагрузок, а на хостинге не дают ставить сторонний софт. Ну и если мне в рамках одного задания, где как раз нельзя было использовать сторонние приложения, пришлось реализовать данный функционал, то почему бы не поделиться.

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

Один из самых быстрых способ межпроцессного взаимодействия реализуется при помощи разделяемой памяти (Shared Memory). Но мне казалось не логичным, что в найденных мною алгоритмах, память всё равно нужно копировать, а после перезапуска клиента (причём он допускался только один) нужно перезапускать и сервер. Взяв волю в кулак, я решил разработать полноценный клиент-сервер с использованием разделимой памяти.

Рассказ о том как я участвовал в highloadcup (чемпионат для backend-разработчиков) от Mail.Ru, написал на php сервер обслуживающий 10000 RPS, но всё равно не получил победную футболку.

Разделяемая память — самый быстрый способ обмена данными между процессами. Но в отличие от потоковых механизмов (трубы, сокеты всех мастей, файловые очереди ...), здесь у программиста полная свобода действий, в результате пишут кто во что горазд.

Так и автор однажды задался мыслью, а что если … если произойдёт вырождение адресов сегментов разделяемой памяти в разных процессах. Вообще-то именно это происходит, когда процесс с разделяемой памятью делает fork, а как насчет разных процессов? Кроме того, не во всех системах есть fork.

Казалось бы, совпали адреса и что с того? Как минимум, можно пользоваться абсолютными указателями и это избавляет от кучи головной боли. Станет возможно работать со строками и контейнерами С++, сконструированными из разделяемой памяти.

Отличный, кстати, пример. Не то, чтобы автор сильно любил STL, но это возможность продемонстрировать компактный и всем понятный тест на работоспособность предлагаемой методики. Методики, позволяющей (как видится) существенно упростить и ускорить межпроцессное взаимодействие. Вот работает ли она и чем придётся заплатить, будем разбираться далее.