The founders of PHP and Swoole voted against, and the coroutine proposal Fiber sparked heated debate

PHP community launched a vote last week (March 8) to add the Fiber RFC to PHP.

According to the description in Fiber RFC, Fiber is mainly used to implement coroutines for asynchronous I/O, providing independent stack allocation, pause and resume functions for function calls. It will be integrated into PHP as an extension Medium: https://github.com/amphp/ext-fiber.

According to the plan, voting will close on March 22. The latest data is 38 votes in favor and 11 votes against. Judging from the current results, the Fiber RFC is likely to be added to PHP through voting (passing with 2/3 of the yes votes).

The current public voting results show that the two founders - PHP founder Rasmus Lerdorf and Swoole founder Han Tianfeng@matyhtf both voted against .

Swoole is a PHP coroutine framework that provides coroutine and high-performance network programming support for PHP, and provides network server and client modules for multiple communication protocols, which can quickly and easily implement TCP /UDP services, high-performance Web, WebSocket services, Internet of Things, real-time communications, games, microservices, etc., make PHP no longer limited to the traditional Web field. (From Swoole official website introduction)

A post on Reddit quoted the email sent by @matyhtf within PHP, It was mentioned that he was worried that Fiber could only be used in frameworks like AmPHP and would be of no value to other ordinary PHP Web projects. This post caused a lot of discussion on Reddit. Some people believe that Fiber is an upgraded version of generator. It is a minimal core implementation of coroutines and will not have an adverse impact on PHP. Integrating it into PHP is conducive to development and exploration of the future. asynchronous ecology. Some people also questioned that @matyhtf voted against it because of concerns about the impact this proposal would have on the commercialization of Swoole (Swoole Plus).

Someone moved this post to the domestic community, which also caused intense discussion. @matyhtf responded with his opinion that Fiber is not complete yet and should be validated as a PECL extension first, rather than directly integrated into PHP. @matyhtf's answer on Zhihu wrote :

What I want to express is that "Fiber is mainly used by asynchronous frameworks implemented by PHP such as amphp and reactphp. Not of much value for normal PHP web projects".

……

My opinion about Fiber RFC is that it is recommended to be a PECL extension first, and PHP core developers can think clearly about the overall technical system and implementation of PHP’s future coroutines before doing it. Decide. In fact, asynchronous programming subverts PHP's long-standing design philosophy and programming model. If the PHP language officially decides to support asynchronous/coroutine concurrent programming models like Node.js, Golang, and Swoole, then it will need to systematically think about the overall architecture and complete implementation.

@matyhtf stated that his vote against the Fiber RFC had nothing to do with Swoole, as Swoole is a purely open source technology project, not a commercial product. If possible, he is even willing to modify Swoole's Copyright and contribute the source code of swoole-src to php-src. However, regarding PHP's proposal to support coroutines, he believes that this is a major change that should be discussed in depth and redesigned from the aspects of syntax, standard library, and ZendVM, rather than making a hasty decision.

@matyhtf continued to publish an article (Fiber RFC about PHP 8.1) explaining in detail the reasons for his opposition to Fiber RFC from technical details. He believes that what users really need is a complete, systematic, systematic, easy-to-use, and reliable set of technical solutions. Based on his own experience, he proposes seven aspects to consider:

• EventLoop API

• ##Coroutine (corresponding to ext-fiber)

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

• CPU Scheduler

• How can existing synchronous blocking IO extensions (redis, curl, php_stream, sockets, mysqli, pdo_mysql, etc.) and built-in functions (sleep, shell_exec, sleep, gethostbyname, etc.) support coroutines? Asynchronous non-blocking mode

• Coroutine communication (channel)

• Server: implement the PHP-FPM coroutine version, or provide a new coroutine ChengHttpServer

Although @matyhtf gave good reasons to vote against it, it seems that many people do not approve of his approach. They believe that even if it is difficult to implement coroutineization of PHP, there is no need to wait until there is a mature solution before merging it. Nor can they guess that Fiber cannot meet the requirements of most people just because it is not perfect enough. On the contrary, because Fiber is a minimal implementation, integrating it into PHP will not impose a large maintenance burden on users, but it can meet the project needs of many people. They can carry out more implementations on this basis, opening up various possibilities for users to explore. The possibility of a coroutine solution.

Therefore, this group of developers sees no reason to object to adding Fiber RFCs to PHP. Both parties think from different perspectives, so they gave completely opposite voting results, and they both have their own positions - although the original intention is to make PHP better, in any case, the voting results will prevail in the end.