Хм. Ввиду того, что РНР запустить на постоянной основе (как сервис) достаточно затруднительно, можно применить несколько вариантов:
- Библиотека Process Control как раз для создания форков/потоков. Коими даже можно в некоторых пределах управлять.
Минусы: требует никсового сервера и оно по умолчанию не поставлено и необходимо иметь доступ к системе, чтобы его поставить. А такое не везде можно.
- Сделать цепную реакцию - каждый скрипт перед завершением запускает один или несколько новых скриптов в зависимости от условий... Получается такая независимая многопоточность. Управление параллельными потоками весьма затруднительно, хотя и возможно. Причём тут можно много вариаций - равноправные потоки, главный и второстепенный (т.е. вызываемый из главного и управляемый им без завершения главного), несколько главных, несколько второстепенных... В зависимости от архитектуры =)
Одна из схем мне представляется примерно такой: клиент тыкается в какой-то известный адрес, который прослушивается главным скриптом, скрипт смотрит - какие порты сейчас свободны, запускает второстепенный скрипт для клиента, который открывает соединение на свободном порту, отмечает в базе его занятость и передаёт клиенту сообщение, что всё хорошо - переткнись на новый порт. Где они и общаются. Как скрипт для клиента завершается (клиент ушёл или отвалился) - он закрывает сокет и сообщает, что порт освободился, и завершается. Опять же общаться можно между скриптами через базу, например. Через какую-нибудь очередь сообщений...
Минусы: жестоко и требует доступа к функциям системных вызовов. Опять же есть не везде.
Вариант самому написать расширение для потоков возможен, но относится к разряду мазохизма и не рассматривается =D
Хм, получается, что везде требуется определённый повышенный доступ к системе .-. А если он есть - проще уж писать на чём-то ином, чем так мучаться.