PHP-Community hat letzte Woche (8. März) eine Abstimmung gestartet, um den Fiber RFC zu PHP hinzuzufügen.
Laut der Beschreibung in Fiber RFC wird Fiber hauptsächlich zur Implementierung von Coroutinen für asynchrone E/A verwendet und bietet unabhängige Stapelzuweisungs-, Pausen- und Fortsetzungsfunktionen für Funktionsaufrufe. Außerdem wird es als Erweiterung in PHP integriert: https :/ /github.com/amphp/ext-fiber.
Planmäßig endet die Abstimmung am 22. März. Die neuesten Daten lauten 38 Ja-Stimmen und 11 Nein-Stimmen. Nach den aktuellen Ergebnissen zu urteilen, ist es wahrscheinlich, dass der Fibre RFC durch eine Abstimmung zu PHP hinzugefügt wird (Verabschiedung mit 2/3 der Ja-Stimmen).
Die aktuellen Ergebnisse der öffentlichen Abstimmung zeigen, dass die beiden Gründer – PHP-Gründer Rasmus Lerdorf und Swoole-Gründer Han Tianfeng @matyhtf – beide dagegen gestimmt haben.
Swoole ist ein PHP-Coroutine-Framework, das Coroutine- und leistungsstarke Netzwerkprogrammierungsunterstützung für PHP bietet. Es bietet außerdem Netzwerkserver- und Clientmodule für mehrere Kommunikationsprotokolle, mit denen TCP/UDP-Dienste und leistungsstarkes Web schnell und einfach implementiert werden können , WebSocket-Dienste, Internet der Dinge, Echtzeitkommunikation, Spiele, Microservices usw. machen PHP nicht mehr auf den traditionellen Webbereich beschränkt. (Aus der offiziellen Website-Einführung von Swoole)
Ein Beitrag auf Reddit zitierte eine von @matyhtf in PHP gesendete E-Mail, in der erwähnt wurde, dass er besorgt sei, dass Fiber nur in Frameworks wie AmPHP und für andere verwendet werden könne Gewöhnliche PHP-Webprojekte haben keinen Wert. Dieser Beitrag sorgte für viele Diskussionen auf Reddit. Einige Leute glauben, dass es sich bei Fiber um eine minimale Kernimplementierung von Coroutinen handelt und dass die Integration in PHP der Entwicklung und Erforschung nicht förderlich ist der Zukunft. Einige Leute stellten auch in Frage, dass @matyhtf dagegen gestimmt hat, weil er sich Sorgen über die Auswirkungen machte, die dieser Vorschlag auf die Kommerzialisierung von Swoole (Swoole Plus) haben würde.
Diskussionen sorgte. @matyhtf antwortete darauf mit seiner Ansicht, dass Fiber noch nicht vollständig sei und zunächst als PECL-Erweiterung validiert werden sollte, anstatt direkt in PHP integriert zu werden. @matyhtfs Antwort auf Zhihu schrieb :
Was ich zum Ausdruck bringen möchte, ist, dass „Fiber hauptsächlich von asynchronen Frameworks verwendet wird, die von PHP implementiert werden, wie z. B. amphp und Reactphp, und dass es für gewöhnliche PHP-Webprojekte keinen großen Wert hat.“ . …Meine Meinung zu Fiber RFC ist, dass es empfehlenswert ist, zuerst eine PECL-Erweiterung zu sein, damit PHP-Kernel-Entwickler klar über das gesamte technische System und die Implementierung der zukünftigen PHP-Coroutinen nachdenken können, bevor sie eine Entscheidung treffen. Tatsächlich untergräbt die asynchrone Programmierung die langjährige Designphilosophie und das Programmiermodell von PHP. Wenn sich die PHP-Sprache offiziell dafür entscheidet, asynchrone/coroutinene gleichzeitige Programmiermodelle wie Node.js, Golang und Swoole zu unterstützen, muss sie systematisch über die Gesamtarchitektur und die vollständige Implementierung nachdenken.@matyhtf erklärte, dass seine Stimme gegen den Fiber RFC nichts mit Swoole zu tun habe, da Swoole ein reines Open-Source-Technologieprojekt und kein kommerzielles Produkt sei. Wenn möglich, ist er sogar bereit, das Urheberrecht von Swoole zu ändern und den Quellcode von swoole-src in php-src einzubringen. Was den Vorschlag von PHP zur Unterstützung von Coroutinen betrifft, ist er jedoch der Ansicht, dass dies eine große Änderung ist, die eingehend diskutiert und unter den Aspekten Syntax, Standardbibliothek und ZendVM neu gestaltet werden sollte, anstatt eine voreilige Entscheidung zu treffen.
- EventLoop API
- Coroutine (entsprechend ext-fiber)
- IO-Planer (Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin)
- CPU-Planer
Wie können vorhandene synchrone blockierende IO-Erweiterungen (Redis, Curl, PHP_Stream, Sockets, MySQLi, PDO_MySQL usw.) und integrierte Funktionen (Sleep, Shell_exec, Sleep, Gethostbyname usw.) Coroutinen unterstützen und zu asynchronen Nicht-IO-Programmen werden? Blockierungsmodus
Coroutine-Kommunikation (Kanal)
Server: Implementieren Sie die PHP-FPM-Coroutine-Version oder stellen Sie einen neuen Coroutine-HttpServer bereit
Obwohl @matyhtf gute Gründe angegeben hat, dagegen zu stimmen, ist es von nun an so Es scheint, dass viele Menschen seinen Ansatz nicht gutheißen. Sie glauben, dass es nicht notwendig ist, mit der Zusammenführung zu warten, bis eine ausgereifte Lösung vorliegt, auch wenn die Coroutineisierung von PHP sehr schwierig ist. Sie können auch nicht vermuten, dass Fiber die Anforderungen von nicht erfüllen kann, nur weil es nicht perfekt genug ist die meisten Leute. Im Gegenteil, da es sich bei Fiber um eine minimale Implementierung handelt, verursacht die Integration in PHP keinen großen Wartungsaufwand für Benutzer, kann jedoch die Projektanforderungen vieler Menschen erfüllen. Sie können auf dieser Basis mehr Implementierungen durchführen, was verschiedene Möglichkeiten eröffnet damit Benutzer die Möglichkeit einer Coroutine-Lösung erkunden können.
Daher sieht diese Gruppe von Entwicklern keinen Grund, Einwände gegen die Hinzufügung von Fiber RFC zu PHP zu erheben. Beide Parteien denken aus unterschiedlichen Perspektiven, geben daher völlig gegensätzliche Abstimmungsergebnisse ab, und beide haben ihre eigenen Positionen – obwohl die ursprüngliche Absicht darin besteht, PHP besser zu machen, werden sich am Ende auf jeden Fall die Abstimmungsergebnisse durchsetzen.