Re: [RFC] Fibers

> 2020年12月18日 上午12:30，Aaron Piotrowski <aaron@trowski.com> 写道： > > Hello everyone! > > I would like to introduce an RFC for adding full-stack fibers to PHP: > https://wiki.php.net/rfc/fibers > > Fibers are primarily used to implement green-threads or coroutines for asynchronous I/O. Fibers > are similar to threads, except fibers exist within a single thread and require cooperative > scheduling of the fibers by the process. Since fibers do not require a full CPU context switch, they > are lightweight and more performant than multi-processing or threading for awaiting I/O. > > An implementation as an extension is at > https://github.com/amphp/ext-fiber > > Fibers are a complex feature. The RFC contains many examples and links to code using fibers to > help explain and demonstrate what is possible, however I’m certain many more questions and > concerns will arise. Looking forward to feedback and discussion. > > Aaron Piotrowski > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Hi there, So glad to see that the RFC of Fiber is back on the agenda. Let me introduce myself first. I'm a very active contributor to Swoole and also a core member of the Swoole developing group. Though Swoole has not been mentioned in the RFC, Swoole has already worked for async/coroutine feature for many years and always doing best in order to be merged into php-src. It's extremely difficult to merge Swoole into php-src fully because Swoole is systematic and complex. Even the coroutine is a core but also a tiny part of Swoole. In recent years, Swoole has been committed to improving stability and overcoming technical problems. It can be said that the current Swoole is very close to the ideal status. What's more, Swoole has been applied widely by advanced enterprises in China. It has been verified by a large amount of real-world applying. We may have more practical experience in many details of the implementation of coroutine technology For the core of Fiber, the context switching of C stack and PHP VM stack, there is no more obvious problem. But there is somewhere worth improving, indeed. Furthermore, we may do more context switching, since Swoole may yield from PHP internal function, which would make the "@" not work. As we could see, the main controversy is what about the FiberScehduler. I think it is designed for the amphp, however, it makes code hard to be comprehended, and it was unnecessary if we just want a minimum coroutine implementation. Just having creation and switching is enough for a minimum coroutine implementation. So did the last Fiber proposal. The implementation of the scheduler is still debatable. Otherwise, compared with the previous Fiber proposal, the most valuable change in the new Fiber proposal is the introduction of C stack coroutine technology. In my opinion, the goal of the new Fiber proposal is not that ambitious. It just eliminates the stack pollution caused by Promise. This makes the style of PHP coroutine neither like the Nodejs which represents the pure stackless coroutine, nor the Lua and Golang which represent pure stack coroutine. Once PHP has a stack coroutine like Fiber, we can do more than what we can do now. Since we can interrupt from PHP internal functions, then we can replace all the implementation of PHP blocking functions, such as sleep(), and we can also replace php_stream so that we can change the implementation of PDO, mysqli, and phpredis into a coroutine way, and we can also make curl become a coroutine version through libcurl's support for multiplexing. In fact, many years ago, amphp-liked solutions were very popular in the Chinese PHP community. But they were replaced by Swoole, eventually. Performance is one of the reasons. Because, indeed, parsing protocol by PHP is disadvantaged compared to parsing by C. Though the amphp-liked solutions dose expand the PHP's capabilities, the performance is not that satisfactory. However, Swoole performs like other static languages. On another hand, the replacement cost. What has been proved is that most PHP programmers want to continue to use common clients such as PDO, mysqli, phpredis, and curl, and the great PHP package and library ecosystem based on these clients is hard to replace. The cost of moving a modern PHP application to Swoole is so low which was unimaginable before. Many success cases there in the community. So what I want to explain is that once the PHP core is ready to accept the Fiber proposal, everyone will start to think, what is the next? Therefore, what Fiber's goal is what the Fiber extension is designed for are particularly important. What I really care about is - does it just simply eliminates the pollution of the stack caused by Promise, or it plans to improve the performance of PHP applications by a hundredfold at a low cost as Swoole did. Regards, Twosee