PHP 社區(qū)上周（3月8日）發(fā)起了將 Fiber RFC 添加到 PHP 的投票。

根據(jù) Fiber RFC 中的描述，F(xiàn)iber 主要用于為異步 I/O 實(shí)現(xiàn)協(xié)程，提供了獨(dú)立棧分配、函數(shù)調(diào)用的暫停和恢復(fù)功能，它將作為擴(kuò)展集成到 PHP 中：https://github.com/amphp/ext-fiber。

按照計(jì)劃，投票將于3月22日截止，最新數(shù)據(jù)為 38 票贊同、11 票反對(duì)。從目前的結(jié)果來(lái)看，F(xiàn)iber RFC 很大可能會(huì)通過(guò)投票從而被添加到 PHP（獲得 2/3 的贊成票即可通過(guò)）。

當(dāng)前公開(kāi)的投票結(jié)果顯示，兩位創(chuàng)始人——PHP 創(chuàng)始人 Rasmus Lerdorf 和 Swoole 創(chuàng)始人韓天峰@matyhtf 均投了反對(duì)票。

Swoole 是一個(gè) PHP 協(xié)程框架，為 PHP 提供協(xié)程、高性能網(wǎng)絡(luò)編程支持，并提供了多種通信協(xié)議的網(wǎng)絡(luò)服務(wù)器和客戶端模塊，可以方便快速地實(shí)現(xiàn) TCP/UDP 服務(wù)、高性能 Web、WebSocket 服務(wù)、物聯(lián)網(wǎng)、實(shí)時(shí)通訊、游戲、微服務(wù)等，使 PHP 不再局限于傳統(tǒng)的 Web 領(lǐng)域。（來(lái)自 Swoole 官網(wǎng)介紹）

Reddit 上的一篇帖子引用了@matyhtf 在 PHP 內(nèi)部發(fā)送的郵件，里面提到他擔(dān)心 Fiber 只能在 AmPHP 這種框架中使用，而對(duì)于其他普通的 PHP Web 項(xiàng)目沒(méi)有價(jià)值。這篇帖子在 Reddit 引起了不少討論，有人認(rèn)為 Fiber 是 generator 的升級(jí)版本，它是協(xié)程的最小化核心實(shí)現(xiàn)，并且不會(huì)對(duì) PHP 產(chǎn)生不利影響，將它集成到 PHP 有利于發(fā)展和探索未來(lái)的異步生態(tài)。也有人質(zhì)疑@matyhtf 投反對(duì)票是因?yàn)閾?dān)心此提案會(huì)對(duì) Swoole 的商業(yè)化 (Swoole Plus) 造成影響。

有人將這篇帖子搬運(yùn)到了國(guó)內(nèi)的社區(qū)，同樣引起了激烈的討論。@matyhtf 對(duì)此進(jìn)行了回應(yīng)，他的觀點(diǎn)是 Fiber 還不夠完善，應(yīng)該先作為 PECL 擴(kuò)展進(jìn)行驗(yàn)證，而不是直接集成到 PHP 中。@matyhtf 在知乎上的答案寫道：

我要表達(dá)的意思是 “Fiber 主要是提供給 amphp 和 reactphp 這樣 php 實(shí)現(xiàn)的異步框架使用的，對(duì)于普通 PHP Web 項(xiàng)目沒(méi)有太大價(jià)值”。

……

對(duì)于 Fiber RFC 我的觀點(diǎn)是，建議先作為一個(gè) PECL 擴(kuò)展，PHP 內(nèi)核開(kāi)發(fā)者能夠思考清楚 PHP 未來(lái)協(xié)程的整體技術(shù)體系和實(shí)現(xiàn)方式后再做決定。實(shí)際上異步編程顛覆了 PHP 一直以來(lái)的設(shè)計(jì)哲學(xué)和編程模式。如果 PHP 語(yǔ)言官方?jīng)Q定要支持像 Node.js、Golang、Swoole 這樣的異步/協(xié)程并發(fā)編程模式，那么就需要系統(tǒng)性思考一下整體的架構(gòu)，以及完整的實(shí)現(xiàn)。

@matyhtf 表示他給 Fiber RFC 投反對(duì)票與 Swoole 無(wú)關(guān)，因?yàn)?Swoole 是一個(gè)純粹的開(kāi)源技術(shù)項(xiàng)目，而不是商業(yè)產(chǎn)品。如果有可能，他甚至愿意修改 Swoole 的 Copyright，并將 swoole-src 的源代碼貢獻(xiàn)給 php-src。不過(guò)對(duì)于 PHP 支持協(xié)程的提案，他認(rèn)為這是一項(xiàng)重大變更，應(yīng)該進(jìn)行深入討論，從語(yǔ)法、標(biāo)準(zhǔn)庫(kù)和 ZendVM 方面進(jìn)行重新設(shè)計(jì)，而不是倉(cāng)促做出決定。

@matyhtf 繼續(xù)發(fā)表文章（關(guān)于 PHP 8.1 的 Fiber RFC）從技術(shù)細(xì)節(jié)詳細(xì)地解釋了自己反對(duì) Fiber RFC 的原因。他認(rèn)為用戶真正需要的是一種完整的、系統(tǒng)性、成體系、簡(jiǎn)單易用、可靠的一整套技術(shù)方案，并根據(jù)自己的經(jīng)驗(yàn)提出可從 7 個(gè)方面進(jìn)行考慮：

• EventLoop API

• 協(xié)程（對(duì)應(yīng) ext-fiber）

• IO 調(diào)度器（Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin）

• CPU 調(diào)度器

• 現(xiàn)有同步阻塞 IO 擴(kuò)展（redis、curl、php_stream、sockets、mysqli、pdo_mysql 等）和內(nèi)置函數(shù)（sleep、shell_exec、sleep、gethostbyname 等）如何實(shí)現(xiàn)支持協(xié)程，變成異步非阻塞模式

• 協(xié)程通信（channel）

• 服務(wù)器：實(shí)現(xiàn) PHP-FPM 協(xié)程版，或者提供一個(gè)新的協(xié)程 HttpServer

雖然@matyhtf 給出了充分的理由投反對(duì)票，但從目前看來(lái)，許多人并不認(rèn)可他的做法。他們認(rèn)為，即便實(shí)現(xiàn) PHP 的協(xié)程化難度很大也不需要等到有成熟方案之后才合并，也不能因?yàn)?Fiber 不夠完善，就猜測(cè)它不能滿足大多數(shù)人的要求。反而因?yàn)?Fiber 是最小化實(shí)現(xiàn)，集成到 PHP 不會(huì)對(duì)使用者造成很大的維護(hù)負(fù)擔(dān)，卻又能滿足很多人的項(xiàng)目需求，他們可以在此基礎(chǔ)上進(jìn)行