On Fri, 12 Mar 2021 at 04:06, 韩天峰 <ra...@swoole.com> wrote: > Hi Dan, > > > We have no commercial purpose on the swoole open source project. This > is a purely technical project. > If possible, we can remove the name of swoole, contribute the source code > of swoole-src to php-src, and transfer the copyright. > Here is just a technical discussion. My opinion is that if PHP will > support fiber/green-threads, this is a major change, should redesign > language syntax, standard library, ZendVM. > This proposal must be discussed extensively and in-depth, should not > make a hasty decision. > > > There are 7 parts to consider with my experience: > > EventLoop API > > > Fiber/Coroutine/GreenThread > > > IO-Scheduler (Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin) > > > CPU-Scheduler > > > Compatible with existing extesions > (php_streams/ext-sockets/ext-redis/ext-mysqli/ext-pdo-mysql/ext-curl ...) > and builtin-functions (sleep/gethostbyname/proc_open/file_get_contents) > > > Service container, How to support php-fpm and provide a coroutine > version of http server > > > Coroutine communication, How to pass messages between two coroutines > > It’s nice to see php has such topic. This may be the key technology in the > next generation of PHP. > > > > Thanks > > > Tianfeng.Han >
So from what I understand, and correct me if I'm wrong, you're against Fibers because it doesn't include all the other systems needed to make them immediately usable with the traditional APIs? This sound a bit to me to wanting to run a marathon before even having learned how to walk. You said it yourself Swoole took *years* to implement all those changes, and which is pure feature creep for what the RFC process is designed for IMHO. The point of this RFC, from what I see, is to bring the foundational system into core upon which one can build upon, be that in userland or in the extension land (when an internal API is added). Upon which all of those different tools can be added to the language independently, via separate RFCs, by being a PHP library or a PHP extension. So can you please explain to us, why *not* adding one of the seven parts you've stated are necessary and doing gradual implementations of the other tools should not be done? Because if the idea is to add all of these tools at once in a massive RFC, I feel this is going the same way as trying to add unicode support to PHP, and we know where that ended. Best regards, George P. Banyard
