PHP コミュニティは先週 (3 月 8 日)、Fiber RFC を PHP に追加するための投票を開始しました。
Fiber RFC の説明によると、Fiber は主に非同期 I/O 用のコルーチンを実装するために使用され、独立したスタック割り当て、関数呼び出しの一時停止および再開機能を提供します。拡張機能 Medium: https://github.com/amphp/ext-fiber。
計画によれば、投票は 3 月 22 日に締め切りとなります。最新のデータでは、賛成 38 票、反対 11 票となっています。現在の結果から判断すると、Fiber RFC は投票によって PHP に追加される可能性があります (賛成票の 2/3 で可決)。
現在の一般投票の結果によると、PHP の創設者 Rasmus Lerdorf と Swoole の創設者 Han Tianfeng @matyhtf の 2 人の創設者が両方とも反対票を投じました。
Swoole は、PHP 用のコルーチンと高性能ネットワーク プログラミング サポートを提供する PHP コルーチン フレームワークであり、複数の通信プロトコル用のネットワーク サーバーおよびクライアント モジュールを提供し、TCP /UDP サービスを迅速かつ簡単に実装できます。 、高性能 Web、WebSocket サービス、モノのインターネット、リアルタイム通信、ゲーム、マイクロサービスなどにより、PHP はもはや従来の Web 分野に限定されなくなりました。 (Swoole 公式 Web サイトの紹介文より )
Reddit の 投稿 は、PHP 内で @matyhtf によって送信された email を引用していました。 Fibre は AmPHP のようなフレームワークでのみ使用でき、他の通常の PHP Web プロジェクトには何の価値もないのではないかと心配していると述べました。この投稿は Reddit で多くの議論を巻き起こしました。Fiber はジェネレーターのアップグレード バージョンであると信じている人もいます。これはコルーチンの最小限のコア実装であり、PHP に悪影響を与えることはありません。PHP への統合は、開発と探索に役立ちます。未来の非同期エコロジー。また、この提案が Swoole (Swoole Plus) の商業化に与える影響を懸念して @matyhtf が反対票を投じたことを疑問視する人もいます。
誰かがこの投稿を国内コミュニティに移したため、激しい議論が発生しました。 @matyhtf は、Fiber はまだ完成していないため、PHP に直接統合するのではなく、最初に PECL 拡張機能として検証されるべきであるという意見で返答しました。 Zhihu に対する @matyhtf の回答は を書きました:
私が言いたいのは、「Fiber は主に amphp や Reactphp などの PHP によって実装された非同期フレームワークによって使用されます。あまり価値はありません」ということです。通常の PHP Web プロジェクトの場合。」
……
Fiber RFC についての私の意見は、まず PECL 拡張であることが推奨されており、PHP コア開発者は、その前に全体的な技術システムと PHP の将来のコルーチンの実装について明確に考えることができるということです。やります、決めてください。実際、非同期プログラミングは、PHP の長年にわたる設計哲学とプログラミング モデルを破壊します。 PHP 言語が Node.js、Golang、Swoole などの非同期/コルーチン同時プログラミング モデルをサポートすることを正式に決定した場合、アーキテクチャ全体を体系的に検討し、実装を完了する必要があります。
@matyhtf は、Swoole は純粋にオープンソース テクノロジー プロジェクトであり商用製品ではないため、Fiber RFC への反対票は Swoole とは何の関係もないと述べました。可能であれば、彼は Swoole の著作権を変更し、swoole-src のソース コードを php-src に提供することさえ喜んでいます。ただし、コルーチンをサポートするというPHPの提案については、性急に決定するのではなく、構文、標準ライブラリ、ZendVMの側面から深く議論し、再設計すべき大きな変更であると同氏は考えている。
@matyhtf は、Fiber RFC に反対する理由を技術的な詳細から詳細に説明する記事 (Fiber RFC about PHP 8.1) を公開し続けました。ユーザーが本当に必要としているのは、完全かつ体系的で、使いやすく、信頼性の高い一連の技術ソリューションであると彼は考えており、自身の経験に基づいて、考慮すべき 7 つの側面を提案しています。
EventLoop API##Coroutine (ext-fiber に対応)
IO スケジューラ (Socket/FileSystem/ChildProcess/Signal /Timer/Stdout) /Stdin)
CPU スケジューラ
既存の同期ブロッキング IO 拡張機能 (redis、curl、php_stream、socket、mysqli、pdo_mysql など) および組み込み関数 (sleep、shell_exec、sleep、gethostbyname など) はどのようにサポートできますか?コルーチン? 非同期ノンブロッキング モード
コルーチン通信 (チャネル)
サーバー: PHP-FPM コルーチン バージョンを実装するか、新しいバージョンを提供しますcoroutine ChengHttpServer
@matyhtf は反対票を投じる十分な理由を述べましたが、多くの人が彼のアプローチを承認していないようです。彼らは、PHP のコルーチン化を実装するのが非常に難しい場合でも、成熟したソリューションが完成するまでそれをマージするのを待つ必要はないと信じています。ほとんどの人が。逆に、Fiber は最小限の実装であるため、PHP に統合することでユーザーに大きなメンテナンス負担を強いることはなく、多くの人々のプロジェクトのニーズを満たすことができ、これをベースにさらに多くの実装を行うことができ、さまざまな可能性が広がります。ユーザーが探索するコルーチン ソリューションの可能性。
したがって、この開発者グループは PHP に Fiber RFC を追加することに反対する理由はありません。両者は異なる視点から考えているため、まったく逆の投票結果が得られ、両者にはそれぞれの立場があります。本来の目的は PHP をより良くすることですが、いずれにせよ、最終的には投票結果が優先されます。
