> 2021年3月12日 上午5:50，Dan Ackroyd <dan...@basereality.com> 写道： > > Hi Twosee, Tianfeng.Han > > I was drafting a longer reply to you both, but I realised I might be > missing some information. > > Please could you disclose the commercial interests of the Swoole > maintainers, and the ties to the for profit companies that provide > services implementing Swoole? > > Having people vote on RFCs who have ties to companies that provide > services via commercial entities isn't unprecedented. For example > zend.com has had employees who are involved in voting on RFCs, but to > a large extent that was done openly, with all of them using zend.com > email addresses. > > twosee wrote: >> Of course, the Swoole community still expects to merge it into php-src at an >> appropriate time. > > What's your idea of an appropriate time and how do you plan to start > this conversation? > > If something hasn't been merged back after 8 years, it sounds > reasonably unlikely that it's ever going to be merged back. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Hi all, The following are some of my personal views, any comment is welcome: > What's your idea of an appropriate time and how do you plan to start > this conversation? Maybe, I misunderstood the rules of the PHP RFC voting. In my opinion, the PHP RFC drafters need to have considerable experience in PHP kernel development (I mean that I don’t think I have met such requirements yet). And the RFC content needs to be fully verified by unit tests and actual projects, and the API or code implementation should be very stable. Once determined, no major changes will be made in principle. But now, there is another way shown in front of me. We can draft an RFC first, then complete it based on community feedback, mark it as experimental, and continue to iterate in the PHP core. What I have to admit here is that drafting Swow's RFC will be more difficult than Fiber, because the content of the former is many times than that of the latter. However, to my surprise, it seems that there are not as many people who care about the details of the internal implementation as I thought. Most people care more about the content in the user space, and things under the user space are very easy to modify. In addition, due to language and network barriers, people active in the Swoole community rarely participate in discussions in the PHP core community. In fact, I started subscribing to the PHP internal mailing list in July 2020 and occasionally show my opinion there. I often worry that incorrect translations will cause my intentions to be misinterpreted, and other members of the Swoole community never participated in discussions. We hardly use non-local social media. I just registered an account on Reddit, a great community exchange website yesterday, and I haven't had time to read all the discussions on that. For all of the above reasons, it is extremely difficult for me to draft the RFC, and I have always hoped that I can make more contributions to other aspects of the PHP kernel, and then try to propose a huge coroutine draft as a goal of PHP9. And I have not taken the first step so far, I am very sorry about that. Anyway, I will share content about Swow soon and try to draft a proposal. > If something hasn't been merged back after 8 years, it sounds > reasonably unlikely that it's ever going to be merged back. Swoole does have a long history, what I have to point out is that the early Swoole did not really participate in the international open-source community. And Swoole switched from the pure asynchronous mode to the coroutine mode in 2018. At that time, we found that the PHP kernel has a good wrapping for various IO operations. We only need to implement the coroutine version of php_stream_wrapper to turn all relevant synchronous clients into coroutine clients or make synchronization blocking file operations into coroutine way. In this case, we can use a very small amount of work to achieve the reuse of most of the original libraries of the PHP native ecosystem. But Swoole gradually becomes a C++ project with some technical plan, so that it makes Swoole hard to be merged into php-src. I started programming in 2017 and contributed to the Swoole project in 2018. In 2019, I learned and mastered almost all the technical content of Swoole. In 2020, I obtained a php.net account. At the same time, I also created a new systematic pure C coroutine project called Swow (for sure, it can be called any other name, but the name Swow is only respect for Swoole because Swow leans in the implementation principle of Swoole and its technical experience) , and I plan to propose a systematic draft of coroutine this year. I have paid my best to accelerate this process. For the PHP community, everyone really needs a real asynchronous/coroutine solution. Therefore, I totally understand the criticism of the slow progress. But, sorry from the bottom of my heart. I can't do it faster. > Are you saying that by adding this Fiber code to core it will prevent > Swoole from functioning? If so, that is concerning. Or are you > simply saying that Swoole doesn't like this implementation and will not use > it with their own code? First of all, please let me pay tribute to your work. I fully understand that the implementation of Fiber could be indeed compatible with Swoole/Swow because theoretically nothing is incompatible. However, undoubtedly, for some reasons I mentioned or not mentioned, this requires a considerable amount of work. Of course, I am not completely denying the feature of Fiber, I just cannot agree with the merger of ext-fiber now. We always regard merging the coroutine system into php-src as a systematic plan. Even if the implementation of ext-fiber is merged, I am still willing to overcome difficulties to make more changes to promote the merger of Swow into php-src, it's my pleasure. > One thing to consider when comparing the Fiber implementation is that the > vast majority of PHP applications are still run behind a web server in > short-lived requests. Unlike Swoole, Swow, and Parallel, it isn't limited > to ZTS or CLI. It might not be the ideal solution, but IMO it is a step in > the right direction for PHP to allow for better async support. There is a misunderstanding here. Swow has made improvements in this area. It supports NTS, ZTS, supports running under all SAPIs (including FPM), and also supports running under all operating systems. Now, Swow's working principle is a bit like Opcache. Opcache will optimize and replace the CPU instructions, which executed by the code, and Swow will replace the blocking system calls with the corresponding coroutine operation. They hardly change the behavior of the code. Opcache makes The program runs faster, and Swow can make the program's IO concurrency better. Therefore, all PHP programs will benefit from it. We can directly use the synchronous-blocking guzzle. Any network IO will only block one coroutine instead of the entire process. You just need to open more coroutines to get better concurrency performance. For amphp and reactphp, after that, `stream_select()` and `curl_multi_select()` will become the coroutine version, and even they will no longer block the entire program. Generally, the solution provided by Swow is completely a superset of Fiber. By the way, Tianfeng’s translation may have caused some misunderstandings. I think what he wants to express is that Fiber is not a feature that can directly benefit all PHP projects. Of course, I know that the RFC has mentioned that Fiber is mainly provided for the author of the framework and library uses. Sorry for this that caused misunderstanding. Regards, Twosee -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
