Les fondateurs de PHP et Swoole ont voté contre, et la proposition de coroutine Fiber a suscité un débat houleux.

La

communauté PHP a lancé un vote la semaine dernière (8 mars) pour ajouter le Fiber RFC à PHP.

Selon la description dans Fiber RFC, Fiber est principalement utilisé pour implémenter des coroutines pour les E/S asynchrones, fournissant des fonctions indépendantes d'allocation de pile, de pause et de reprise pour les appels de fonction, et il sera intégré à PHP. comme extension Dans : https://github.com/amphp/ext-fiber.

Selon le plan, le vote se clôturera le 22 mars. Les dernières données sont de 38 voix pour et 11 voix contre. À en juger par les résultats actuels, le Fiber RFC est susceptible d'être ajouté à PHP par le biais d'un vote (avec 2/3 des votes oui).

Les résultats actuels du vote public montrent que les deux fondateurs - le fondateur de PHP Rasmus Lerdorf et le fondateur de Swoole Han Tianfeng @matyhtf ont tous deux voté contre.

Swoole est un framework de coroutine PHP qui fournit une prise en charge de la coroutine et de la programmation réseau hautes performances pour PHP, et fournit des modules serveur et client réseau pour plusieurs protocoles de communication, qui peuvent implémenter rapidement et facilement les services TCP/UDP. , Web haute performance, services WebSocket, Internet des objets, communications en temps réel, jeux, microservices, etc., font que PHP ne se limite plus au domaine traditionnel du Web. (Depuis l'introduction du site officiel de Swoole)

Un post sur Reddit citait le e-mail envoyé par @matyhtf en PHP, c'était a mentionné qu'il craignait que Fiber ne puisse être utilisé que dans des frameworks comme AmPHP et ne serait d'aucune valeur pour d'autres projets Web PHP ordinaires. Cet article a suscité de nombreuses discussions sur Reddit. Certaines personnes pensent que Fiber est une version améliorée du générateur. Il s'agit d'une implémentation minimale de coroutines et n'aura pas d'impact négatif sur PHP. Son intégration dans PHP est propice au développement et à l'exploration. de l’écologie asynchrone du futur. Certaines personnes ont également remis en question le fait que @matyhtf ait voté contre parce qu'il s'inquiétait de l'impact que cette proposition aurait sur la commercialisation du Swoole (Swoole Plus).

Quelqu'un a déplacé ce message vers la communauté domestique, ce qui a également provoqué de vives discussions. @matyhtf a répondu en affirmant que Fiber n'est pas encore terminé et devrait d'abord être validé en tant qu'extension PECL, plutôt que directement intégré à PHP. La réponse de @matyhtf sur Zhihu a écrit  :

Ce que je veux exprimer, c'est que "La fibre est principalement utilisée par les frameworks asynchrones implémentés par PHP tels que amphp et reactphp. Pas beaucoup de valeur pour les projets Web PHP normaux".

......

Mon point de vue concernant Fiber RFC est qu'il est recommandé d'être d'abord une extension PECL, et les développeurs principaux de PHP peuvent réfléchir clairement au système technique global et implémentation des futures coroutines de PHP avant de le faire. En fait, la programmation asynchrone bouleverse la philosophie de conception et le modèle de programmation de longue date de PHP. Si le langage PHP décide officiellement de prendre en charge les modèles de programmation simultanée asynchrone/coroutine comme Node.js, Golang et Swoole, il devra alors réfléchir systématiquement à l'architecture globale et à la mise en œuvre complète.

@matyhtf a déclaré que son vote contre le Fiber RFC n'avait rien à voir avec Swoole, car Swoole est un projet technologique purement open source, pas un produit commercial. Si possible, il est même prêt à modifier les droits d'auteur de Swoole et à contribuer le code source de swoole-src à php-src. Cependant, concernant la proposition de PHP de prendre en charge les coroutines, il estime qu'il s'agit d'un changement majeur qui devrait être discuté en profondeur et repensé du point de vue de la syntaxe, de la bibliothèque standard et de ZendVM, plutôt que de prendre une décision hâtive.

@matyhtf a continué à publier un article (Fiber RFC à propos de PHP 8.1) expliquant en détail les raisons de son opposition à Fiber RFC à partir de détails techniques. Il estime que ce dont les utilisateurs ont réellement besoin, c'est d'un ensemble complet, systématique, facile à utiliser et fiable de solutions techniques. Sur la base de sa propre expérience, il a proposé sept aspects à considérer :

• .

  API EventLoop

• Coroutine (correspondant à ext-fiber)

• Planificateur IO (Socket/FileSystem/ChildProcess/Signal /Timer/ Stdout/Stdin)

• Planificateur CPU

• Comment les extensions IO de blocage synchrone existantes (redis, curl, php_stream, sockets, mysqli, pdo_mysql, etc.) et les fonctions intégrées (sleep, shell_exec, sleep, gethostbyname, etc.) peuvent prendre en charge coroutines, deviennent mode asynchrone non bloquant

• Communication coroutine (canal)

• Serveur : implémenter la version coroutine PHP-FPM, ou fournir un nouvelle coroutine Cheng HttpServer

Bien que @matyhtf ait donné de bonnes raisons de voter contre, du point de vue actuel, de nombreuses personnes n'approuvent pas son approche. Ils pensent que même s'il est très difficile de mettre en œuvre la coroutineisation de PHP, il n'est pas nécessaire d'attendre qu'il existe une solution mature avant de la fusionner. Ils ne peuvent pas non plus deviner que simplement parce que Fiber n'est pas assez parfaite, elle ne peut pas répondre aux exigences de. la plupart des gens. Au contraire, étant donné que Fiber est une implémentation minimale, son intégration dans PHP n'entraînera pas une grosse charge de maintenance pour les utilisateurs, mais elle peut répondre aux besoins du projet de nombreuses personnes. Ils peuvent réaliser davantage d'implémentations sur cette base, ouvrant ainsi diverses possibilités. que les utilisateurs peuvent explorer. La possibilité d'une solution coroutine.

Par conséquent, ce groupe de développeurs ne voit aucune raison de s'opposer à l'ajout de Fibre RFC à PHP. Les deux partis pensent selon des perspectives différentes, ils ont donc donné des résultats de vote complètement opposés, et ils ont tous deux leurs propres positions - bien que l'intention initiale soit d'améliorer PHP, dans tous les cas, les résultats du vote finiront par prévaloir.