PHP 社群上週（3月8日）發起了將 Fiber RFC 加入 PHP 的投票。
根據Fiber RFC 中的描述，Fiber 主要用於為非同步I/O 實作協程，提供了獨立堆疊分配、函數呼叫的暫停和復原功能，它將作為擴充整合到PHP中：https://github.com/amphp/ext-fiber。
依照計畫，投票將於3月22日截止，最新數據為 38 票贊同、11 票反對。從目前的結果來看，Fiber RFC 很大可能會透過投票從而被添加到 PHP（獲得 2/3 的讚成票即可通過）。
目前公開的投票結果顯示，兩位創辦人－PHP 創辦人Rasmus Lerdorf 和Swoole 創辦人韓天峰@matyhtf 都投了反對票。
Swoole 是一個PHP 協程框架，為PHP 提供協程、高效能網路程式設計支持，並提供了多種通訊協定的網路伺服器和客戶端模組，可以方便快速地實現TCP /UDP 服務、高效能Web、WebSocket 服務、物聯網、即時通訊、遊戲、微服務等，使PHP 不再局限於傳統的Web 領域。 （來自Swoole 官網介紹）
Reddit 上的一篇帖子引用了@matyhtf 在PHP 內部發送的郵件，裡面提到他擔心Fiber 只能在AmPHP 這種框架中使用，而對於其他普通的PHP Web 專案沒有價值。這篇文章在Reddit 引起了不少討論，有人認為Fiber 是generator 的升級版本，它是協程的最小化核心實現，並且不會對PHP 產生不利影響，將它集成到PHP 有利於發展和探索未來的異步生態。也有人質疑@matyhtf 投下反對票是因為擔心此提案會對 Swoole 的商業化 (Swoole Plus) 造成影響。
有人將這篇貼文搬運到了國內的社區，同樣引起了激烈的討論。 @matyhtf 對此進行了回應，他的觀點是 Fiber 還不夠完善，應該先作為 PECL 擴展進行驗證，而不是直接集成到 PHP 中。 @matyhtf 在知乎上的答案寫道：
我要表達的意思是「Fiber 主要是提供給amphp 和reactphp 這樣php 實作的非同步框架所使用的，對於普通PHP Web 專案沒有太大價值」。
……
對於Fiber RFC 我的觀點是，建議先作為一個PECL 擴展，PHP 核心開發者能夠思考清楚PHP 未來協程的整體技術體系和實作方式後再做決定。實際上非同步程式設計顛覆了 PHP 一直以來的設計哲學和程式模式。如果 PHP 語言官方決定要支援像 Node.js、Golang、Swoole 這樣的非同步/協程並發程式模式，那麼就需要係統性思考整體的架構，以及完整的實作。
@matyhtf 表示他給 Fiber RFC 投下反對票與 Swoole 無關，因為 Swoole 是一個純粹的開源技術項目，而不是商業產品。如果有可能，他甚至願意修改 Swoole 的 Copyright，並將 swoole-src 的原始碼貢獻給 php-src。不過對於 PHP 支援協程的提案，他認為這是一項重大變更，應該進行深入討論，從語法、標準函式庫和 ZendVM 方面進行重新設計，而不是倉促做出決定。
@matyhtf 繼續發表文章（關於 PHP 8.1 的 Fiber RFC）從技術細節詳細地解釋了自己反對 Fiber RFC 的原因。他認為使用者真正需要的是一種完整的、系統性、成體系、簡單易用、可靠的一整套技術方案，並根據自己的經驗提出可從7 個方面進行考慮：
#EventLoop API
協程（對應ext-fiber）
IO 調度器（Socket/FileSystem/ChildProcess/Signal /Timer/Stdout/Stdin）
CPU 調度器
現有同步阻塞IO 擴充（redis、curl、php_stream、sockets、mysqli、pdo_mysql 等）和內建函數（sleep、shell_exec、sleep、gethostbyname 等）如何實現支援協程，變成異步非阻塞模式
協程通訊（channel）
#伺服器：實作PHP-FPM 協程版，或提供一個新的協程HttpServer
雖然@matyhtf 給了充分的理由投反對票，但從目前看來，許多人並不認可他的做法。他們認為，即便實現 PHP 的協程化難度很大也不需要等到有成熟方案之後才合併，也不能因為 Fiber 不夠完善，就猜測它不能滿足大多數人的要求。反而因為Fiber 是最小化實現，整合到PHP 不會對使用者造成很大的維護負擔，卻又能滿足許多人的專案需求，他們可以在此基礎上進行更多實現，為用戶開放了探索各種協程方案的可能。
因此，這部分開發者認為沒有理由反對將 Fiber RFC 加入 PHP。雙方思考角度不同，所以給出了截然相反的投票結果，而且他們都有各自的立場——雖然初衷都是希望 PHP 變得更好，但無論如何，最後還是以投票結果為準。
