Swoole维护者缺乏信心吗？ 来自PHP核心维护者的思想

你可能会知道我是想要摆脱PHP短标签的人，将::令牌重命名为T_Double_Colon，或者你的人＆＃39;如果你曾经打过一个新引入的价值交易，那么它可能是诅咒。我＆＃39; ve曾在PHP-SRC上工作了大约2年，而PHP文件约为3.因此我在PHP RFC上有投票权。

正如您可能知道的那样，纤维RFC目前正在进行投票中包含在PHP核心中。我应该前言，这不是异步编程中的专家，我从未使用过Swoole，也不是放大器，也不是Reactphp，我对Node.js的用法已经相当有限，但我试图做出明智的决定和因此，有一些阅读并与RFC作者谈论澄清。我也提到有可能投票的原因，如增加项目的维护负担，这可以作为延伸，不提供足够的建筑块等，而不是每个人（实际上是大多数人）至少没有选民与Swoole项目没有与我的知识相关联。

然而，随着这个空间的一个项目，Swoole人是最多的声音，而是在这个空间中的一个项目，我试图了解他们的推理。从我可以看到的是，他们正在推动那些患有异步编程的Node.js方式，这遭受了＆＃34;你的功能是什么颜色的？＆＃34;问题。这是一个关键文章，用于为什么纤维（也称为绿色线程或共惯性）是一个优越的模型。

从答复到官方PHP内部列表Swoole成员的反馈/疑虑一直是以下情况。 [以我自己的话语摘要]一个哲学课程与纤维类的哲学之一不应该是最终的，关于它的C执行的各种担忧（关于但这主要是关于与新的内部观察者API的集成，以及缺乏C API为了添加共同程序，只要接受该提案即可修改的东西），据称与水卷发不相容。最后一点非常有关，但似乎还拔出了薄的空气，因为Swoole和Ext-Fiber（基于该提议的ext-Fired（基于该提案）使用升压组装文件，因此我会想象当添加C API时，这将成为一个非问题，但这仍然是一个有效的理由，以便在其目前的状态下投反对票它没有提供一个。

随着SWoole团队提出的另一个主要角度是这种添加了这个添加了PHP神奇的异步，对我来说是错过了这个提案的重点。但他们确实提供了7个组件所需的php是异步，即：

服务容器（如何支持PHP-FPM和/或提供HTTP服务器的共常规版本）

这些组件中的一些可以在User-Land中进行（即事件循环，I / O调度程序，即使是HTTP服务器也可以在PHP中制作），我不知道是否有可能在User-Land中做关于共同常规通信的最后一点，可以通过使用生成器和将值发送到它可以通过生成器:: send（）方法来产生的。

从RFC来看，我们可以看到这个提议很好地与各种扩展和分析器（xdebug甚至从框中练习），我可以想到的唯一其他不兼容是，再次缺少FIBERS的C API。

CPU调度程序组件肯定无法在用户陆中完成，但我也无法理解为什么需要为什么需要，因为从我的理解，整个光纤点不依赖于操作系统线程，可以使用并行使用扩大。

尽管讨论正在缓慢进展，因此由于语言障碍和时区差异，它是可以理解的，因为大多数维护者都是中国人的理解。但是，我所做的问题是，在列表（Twitter / Reddit）之外，在列表中传达至关重要的信息，这可能是由于这些帖子的性质而被认为是一个涂片运动。在我看来，这是一个特别是令人震惊的是它源于在PHP RFC进程中投票的人，并且显然是名单。

我会注意到我＆＃39; ll总是捍卫某人，因为没有给予RFC的原因，它完全在他们这样做，但如果你在提供上下文的同时，它应该在列表中完成所涉及的每个人都可以做出明智的决定，这可能导致更多人投票反应。

到底，这让我们离开了吗？从我的理解＆＃39; s值基于纤维顶部内置的工具集和API，而不是本身。如果它与Swoole从根本上不相容的情况下，我可以了解这一提议的阻力，但如前所述，它是＆＃39; t。因此，只有一个结论即可到达：对于Swoole维护者，引入纤维，允许其他项目，如放大器，Reactph，Symfony，Guzzze，PSALM等。利用它们来改进，将大大降低价值他们提供（作为唯一一个在此时拥有这样的本土系统的一个）到一个不可急的点。

对我来说似乎非常奇怪的东西，因为它们在异步和非阻塞API上有一个多年的头部开始。