在最近的 PHP 版本 (>5.3) 中，我找不到stream_socket_client()和相关fsockopen()的是否是合理的线程安全的。
我最感兴趣的是 Apache 上的 PHP，在 Linux 上。还有 Apache MPM-prefork 是否有所作为，以及是否存在知识，如果这一切都适用于例如 Nginx 下的 fastCGI。
一个简短的测试告诉我，每个分支都会创建自己的套接字文件，但这对于更多并发连接是否适用？这是由于 Apache 的分叉、Unix 的套接字架构还是 PHP 本身的性质？当谈到这些接近金属的问题时，我一无所知。
或者：是否可以安全地假设在读取和写入源时stream_socket_client()永远不会在不同的连接上发生冲突？
关于 pthreads：
此时 PHP 的架构是一成不变的 - 阅读 PHP6 - 所以事实是，你现在或将来能够线程化任何你认为是 PHP 的唯一方法是通过 PECL 扩展，但是你不应该让这让你失望——你不会仅仅因为 APC 不是核心的一部分就从你的网络中放弃 APC 的能力。我可能有点偏见，因为我是 pthreads 的唯一作者，但我没有使用过 voodoo 或法术，我使用的是 Objects API，结合 TSRM 和扩展 API - 所有的东西多年来一直在酝酿，并进行了数十亿小时的实际测试，这并不是说 pthreads 已经准备好生产，当然不是，但总有一天它会。
pthreads 可能永远不会共享资源，我已经对此进行了长时间的试验，并且我找到了多种让它工作的方法，但没有一个是令人满意的。PHP 主要是扩展（甚至标准库也是作为扩展实现的——这是添加功能的最有效方式），它们都没有为对象级多线程环境做好准备。由于许多原因，PHP 不是多线程网络应用程序的理想选择。当您以非线性方式思考时，为什么要共享资源，（除了套接字 - 使用更合适的东西）资源可以在完全不同的线程中创建和操作，同时您继续解析您的业务模板或 json 或您的应用程序所做的任何事情。
PHP 本身对线程的支持很少。它可能会或可能不会对“线程安全”的函数做出承诺，但是当解释器本身假装线程不存在时，这几乎没有什么区别。*
不过，就 mpm_prefork 而言，这并不重要。Prefork MPM 完全是关于分叉（因此得名）。它不打扰线程，所以 PHP 的线程安全问题并没有真正出现。
我不太了解 FastCGI（尤其是它与老式 CGI 的区别），但除非它需要解释器的大量特殊支持，否则它也会使用多进程模型而不是多线程模型。每个解释器都有自己的进程，这使得 PHP 对线程的支持几乎无关紧要。
* 有一个 PECL 模块为 PHP 提供了一种使用 pthreads 的方法，但它不是核心的一部分，我想当线程开始发挥作用时，有一大堆扩展会彻底崩溃。我认为 PHP 中的线程远未成熟到足以用于生产用途，并且可能会继续这种感觉，直到 PHP 本身提供了一种创建线程的方法。