на php окрывается порт,



переменная $sock явяется ресурсом, т.е. указателем на некую структуру.


Можно ли как-то сохранить $sock  в бд, чтобы Второй скрипт обратился к нему, и дальше уже работал с открытом портом?


т.е. цель такая:

Скрипт1 открывает порт, сохраняет ресурс в бд
Скрипт2 берёт ресурс из бд, и работает с открытым портом


Возможна ли такая схема? Как сохранить ресурс в БД?

Нет, у слова "указатель" есть устоявшэеся значение, и $sock ему не соответствует.



Чтобы сокет был открыт и доступен для пользовательских программ -- обязательно требуется, чтобы он в каждый момент времени открыт в каком-нибудь выполняющемся процэссе. Открытие -- это вот то, что делаешь ты, по факту эта последовательность действий вызывает похожэ поименованные функцыи ядра ОС для того, чтобы ядро проделало внутри себя операцыи по открытию (заполнение нескольких структур и посылка нескольких пакетов в есть) -- и вернуло номер, который будет использоваться для идэнтификацыи сокета в этом процэссе. Передать открытый сокет другому процэссу в том жэ экземпляре ОС (до перезагрузки) -- вполне реально (см. SCM_RIGHTS).
 Поскольку существующие сервера БД совершэнно не предназначены работать хранителями пользовательских сокетов -- то передать открытый сокет в существующую БД никак невозможно (в БД нет процэдуры, спецыального кода, который мог бы получить ужэ открытый сокет), обратно -- тожэ, да и хранить его в БД негде.
Но, конечно, можно написать свою БД, которая будет работать именно свалкой открытых сокетов.

ну вот например в делфи всё просто, в качестве сокета просто числовое значение типа dword, чтобы другой поток в пределах одного приложения работал с сокетом, достаточно просто передать впоток этот номер.


Получается в php запуск нового скрипт можно сравнить с запуском нового приложения? 
Я почему-то думал что можно запустить несколько скриптов, чтобы они работали как многопоточное приложение, где каждый скрипт это поток.


Тогда такой вопрос, установлен обычный FreeBSD сервер, с ISPManager, существуют ли какие модули или расширения для разработки многопоточного приложения, и работы с сокетами?

можно форкнуть дочерний процесс через pcntl_fork(). все открытые дескрипторы будут ему доступны.
http://ideone.com/ngUvH1

Добавлено через 5 минут и 6 секунд
хотя идея передавать в разные процессы дескриптор сокета, открытого на прослушивание, весьма странная.
слушает один процесс. при запросе соединения запускается дочерний для его обработки (при этом accept() возвращает новый дескриптор, связанный с конкретным соединением).

ЗЫ: проблема хранения в бд не только в том, что resource это внутренняя структура zend engine, но и в правах на дескриптор. даже зная значение, произвольный процесс не сможет им воспользоваться: в php нет способа установить права на сокет (если таки есть, поправьте меня).

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

Передать любой дескриптор другому процэссу -- вполне можно, см. man unix по слову SCM_RIGHTS.

Добавлено через 8 минут и 40 секунд


Да, конечно. Варианты работы php когда это не совсем так, для ускорения -- имеются, но в php сделано многое для того, чтобы от запуска свежэго приложэния это никак не отличалось.




Наверное, есть, не знаю (если потребуется -- пойду в гугль). А Вам зачем? То есть  мне просто достаточно сложно представить задачу, в которой приложэние на php имело бы смысл делать многопоточным. Сложная асинхронная логика с большыми временами ожыдания? Это всё равно web-API -- так и делай логику через собирание RPC/веб-запросов.
Нужна скорость при большых объёмах операцый на совместно используемой памяти? Перепишы с PHP на C -- будет в разы быстрее, чем все варианты php с трэдами.

в unix, но не php

файловые дескрипторы у каждого процесса свои, но ОС умеет делать копии для другого процесса. для дочерних процессов это делается автоматически, для чужих есть sendmsg. не очень понятно как это использовать в php даже несмотря на наличие в 5.5 socket_sendmsg()


помимо упомянутого fork() в php есть расширение pthreads, представленное классами Thread, Worker и тд


а на Python?

А для питона сложно представить хоть какую-то задачу, которую бы имело смысл на нём делать.

Но, в отличие от PHP -- python -- это менее обязательно web, а в варианте классического демона асинхронная логика на трэдах можэт иметь смысл. И в варианте пользовательского приложэния -- тожэ. Хотя это само по себе, конечно, несколько на любителя. Ну, то есть, по сравнению например с erlang все такие вещи, кроме сделанных на Си для скорости или на java для простоты установки на кофеварки, выглядят безсмысленно переусложнёнными. А уж на мой личный взгляд -- так и событийно-ориентированная машына состояний удобнее будет.