Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113428 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21598 invoked from network); 10 Mar 2021 02:11:23 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Mar 2021 02:11:23 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D62FA1804B8 for ; Tue, 9 Mar 2021 18:03:20 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RDNS_DYNAMIC,T_SPF_TEMPERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from qq.com (out203-205-221-231.mail.qq.com [203.205.221.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 9 Mar 2021 18:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1615341796; bh=6VlpU2k1MCCskOAV3zFAggb2ipXj6nVaLaDsvjTcyB0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=UEJC0gkeK/M2cOQ7TPvtxJsFtxmfVLy1MHJeBJg2D62hctJJBl/2DCEm0PW8kEus5 RZN2lb4AM49Nc/MPL72YrLcJZkj8m4LAqVGlS2flmwJXfg8azb6y/AwVApRxr/hqlZ ySwp9h1413CLZFJyI2rPJgstIYpV05HetyJcSKRU= Received: from [127.0.0.1] ([113.98.52.82]) by newxmesmtplogicsvrsza8.qq.com (NewEsmtp) with SMTP id CE26419; Wed, 10 Mar 2021 10:03:14 +0800 X-QQ-mid: xmsmtpt1615341794tsd1odfvd Message-ID: X-QQ-XMAILINFO: OeUpCsyuJbBNe9cEZB4yALBwbtQ3pWR2Gmw4LvKLGmy8maWptkgCvT9PoYNX6Z ZMk42Sej3o+uajLlJXL0lNCX+5bX2BwzVyuEol2we2r3Akhkua4BLT44QSpXdN/xRgXqpjz3ktz9 qCXyewAIMWGL78XIIp00vlA4xNT87otBsCKZrwXgAn8KjWKr+jfuoyx5VZkRdi7qNvLYTuvx+jgY 4jeqYdZgKlHSmRlWXk3k+8eVXrEIBq/rA81laetGBNlK/sWS90bfAs8x74eLtMBBFVNBY3T1309t 1n1S/hiF3eiGr+koyt8weHD8U4BL8vn5o++GEq8meUNaITk+3UtFeMuDm5tv56YBwBgptKPdX8FS XlF3VU2XqB7CU22uHIyqjR1xl5KE1pAsMF0lQ1oRl8Vt9IH2HmjSnCEHv/CchoeFuXg6O+vouISE 907gnILf2ENHzHJopeN0xfW0W7l/RQOiZU5YJJNBJl2aafFhJELD/LrnFQoCDmJ9EgMwei6pynyY o2duR9q7lGsZqlfu38kNNx4rMZy3s47JiVrGAgOZeA170AVn+0aOmdT57NmvFbuKI560t+XCO+Xr V5p1Jwgpt5MGTpqVZ9mlaU/msoZDcub1lIufERA4I2LSw0PZPYrKzOKSloxobVQS/RgKj5RvjZY+ LowAXn/wrSh0ONdC6zGF98BBugyPlwCu35+OjUzJKepoze+zrfheJFArnikGibL6QItR5wZfCQOO WJvxWXSN3meZJ8kqU4zNfT5A== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) In-Reply-To: <8812EE70-4720-4639-926E-1EA206624BC1@trowski.com> Date: Wed, 10 Mar 2021 10:02:49 +0800 Cc: php internals Content-Transfer-Encoding: quoted-printable X-OQ-MSGID: References: <8812EE70-4720-4639-926E-1EA206624BC1@trowski.com> To: Aaron Piotrowski X-Mailer: Apple Mail (2.3654.60.0.2.21) Subject: Re: [PHP-DEV] [VOTE] Fibers From: twose@qq.com (twosee) > 2021=E5=B9=B43=E6=9C=8810=E6=97=A5 =E4=B8=8A=E5=8D=882:58=EF=BC=8CAaron = Piotrowski =E5=86=99=E9=81=93=EF=BC=9A >=20 >=20 >> On Mar 8, 2021, at 1:40 PM, Aaron Piotrowski = wrote: >>=20 >> Greetings everyone! >>=20 >> The vote has started on the fiber RFC: = https://wiki.php.net/rfc/fibers >>=20 >> Voting will run through March 22nd. >>=20 >> Cheers, >> Aaron Piotrowski >=20 > Hi all! >=20 > A concern was raised off list that due to the complexity of the way = this feature interacts with the engine, it may be best to mark the = feature as experimental. This would allow some changes to be made to = certain edge-case behaviors and, while I don't think it would be = necessary, the public API. >=20 > We (Niklas and I) agree with this and propose that if this feature is = accepted, it is marked as experimental through the 8.x release cycle or = until we're comfortable removing that label, whichever comes first. >=20 > Experimental in this context would mean fibers would be compiled and = available in all releases, but the documentation would denote that = behavioral and API changes may be made in future minor releases =E2=80=93 = use at your own risk. >=20 > As this feature is targeted at library authors and not average PHP = users, we believe there would be little effect to the community to take = this step. >=20 > Cheers, > Aaron Piotrowski > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >=20 >=20 Sorry for being late, writing an English manuscript is still a bit = difficult for me. Here I want to continue to express some of my views. Firstly, I want to emphasize that the separate Fiber API has no meaning = to users. Many people have a misunderstanding about this. They think = that the Fiber feature can make PHP have the same high-performance = network programming capabilities as Golang and support it blindly. There = is a complete and complex system behind Goroutine. In terms of the = amount of work implemented, the context switching capability, which is = the capability provided by the ext-fiber extension, is only a very = insignificant part. In my opinion, Fiber is just an enhancement of Generator. As far as my = superficial understanding is concerned, the evolution direction of amphp = and reactphp should be similar to that of node.js. And node.js is not = implemented with on any stacked-coroutines. In theory, the performance = of stackless-coroutine is better. Furthermore, the implementation of = await/async does not require stacked-coroutine. Therefore, I'm confused = about the content of the Fiber proposal, because, it seems to put it in = the wrong direction. The implementation of the coroutine and the entire system are = complementary and inseparable. With the optimization and update of the = entire system, there will be more and more customization requirements, = which influence the implementation details of the coroutine. This is = also the reason why Swoole did not merge its coroutine capabilities into = php-src, individually. As stripping out a separate coroutine extension, = many customized things will lose their reason for existence. Therefore, = we hope to incorporate the entire system, which will make everything = more logical. As Nikita said, if it is unnecessary, it is better to let the expansion = stay in PECL, which will bring more freedom to the project and be more = conducive to the rapid development of the project. Swoole has mastered = all the technologies applied to ext-fiber in 2018 and built a complete = network programming system based on coroutine. Since then, in order to = better integrate with the original ecosystem of PHP, Swoole has = coroutinefied PDO, mysqli, phpredis, libcurl, etc., and applied them to = a large number of real-world projects. These projects also contributed = to the development of the PHP coroutine technology and ecosystem. Of = course, the Swoole community still expects to merge it into php-src at = an appropriate time. Therefore, I have to point out that there is no practical experience in = the design of ext-fiber. It skips the progress, which to be a PECL = extension, and does not have any guidance of practical application. This = is very dangerous. The proposal regards the PHP kernel as a large test = ground in the way that incorporating Fiber into php-src as an = experimental feature. And one of the main reasons is simply that the = installation of extensions is difficult for some users. For many years, = I have always thought that the PHP kernel's attitude towards merging = anything is scientific and rigorous, so I have always been cautious and = respectful. But this time, it makes me confused and a little bit = disappointed. In various design details, there are still many questions that make me = confused. I will point out a few here: 1. Fiber class should not be designed as final We should try to avoid any internal class being designed as final unless = there are any necessary security reasons, otherwise, the scalability of = the class will be greatly restricted. For instance, in practice, we = usually assign a Context for every Fiber, it seems like $GLOBALS, so = that we can write like this class MyFiber extends \Fiber { public $context =3D []; } Or, we can add a custom log for the switch of the coroutine, or switch = some contexts we want to switch class MyFiber extends \Fiber { public function resume(...$data):mixed { log('resume to {$this->getId()}'); return parent::resume($data); } } There are also some coroutine frameworks that want to track and count = the coroutines created by users and will perform some injection = operations, so they have their own special version of the coroutine = implementation. If inheritance is not possible, then we need twice the = number of objects, and mounting Fiber as a property on the newly = implemented class. It is bad for performance and very inelegant. If ext-fiber is declared as final for technical reasons, then I can only = say that this is a technically problematic implementation. 2. Coroutine state acquisition problem The ext-fiber defines many methods to obtain the state of the coroutine, = such as isRunning(), etc. Why not directly export the status constants = and provide a getStatus() function, if we just want the simplest = implementation? If there are some internal states on the status, then these states = should be distinguishable. For example, they can be removed by bit = operations or stored on other attributes. The following are some technical issues about the implementation of = ext-fiber. Due to the limited time, I have only read part of the source = code limitedly. Excuse me, if there are any inaccuracies. 1. The code about coroutine switching could be simplified There is essentially only one kind of switch API for coroutines that is = resume(), in boost it called jump(). Its function is to switch to a = coroutine, and yield()/suspend() is equivalent to = $previousCoroutine->resume(). So I can=E2=80=99t understand why resume() = and suspend() are implemented twice in the implementation of ext-fiber. If we indicate the correct implementation of suspend() in PHP, it should = look like this: public static function suspend(...$data): mixed { return static::this()->getPrevious()->resume(...$data); } If there are any technical reasons for implementing resume() twice in = ext-fiber, then I can only say that this is still a wrong = implementation. 2. Switch notification In zend_fiber_switch_to(), call zend_observer_fiber_switch_notify() = twice at the beginning and ending of switch is an obviously wrong = implementation. After we solve the previous problem, we only need to = notify once before switching, because the second notification will be = sent by another coroutine before it's switching back. Other issues 1. C extension support This Fiber proposal is dedicated to providing PHP with coroutine = capabilities, but it does not consider the C extension. For example, it = can consider turning some APIs into function pointers so that other = extensions can add some content. 2. Unsolvable blocking The Fiber proposal mentions the blocking problem but does not give a = good idea or solution to solve it. In the coroutine system, no blocking = is allowed. Blocking will greatly affect the normal operation of the = entire program. Unlike JavaScript, PHP is not a naturally asynchronous = language. Implementing coroutines and EventLoop in the user space can = only solve some blocking from network calls, but other blocking problems = such as file reading and writing, DNS queries, etc., can hardly be = solved. However, PHP is very similar to node.js, which is more suitable = for the 'multi-process with single-thread' model. Therefore, integrating = libuv and tightly combining with coroutine features to achieve a = complete coroutine system is a good asynchronous network IO solution. 3. CPU starvation The capability of the 'multi-process with single-thread' model in CPU = scheduling is not that good as Golang's multi-thread model. Solving the = CPU starvation problem is another issue that needs to be considered For example, in Swow (https://github.com/swow/swow, the latest research = result of the Swoole community), the WatchDog component based on the = monitoring the number of coroutine switching rounds and the interrupt = feature of ZendVM solves this problem. It can issue an alarm when the = CPU starvation occurs. Through configuration or PHP programming, it can = also actively suspend the coroutine when the CPU starvation occurs, = restore the average response speed of the entire program, and even = directly kill the coroutine when the CPU infinite loop occurs. 4. Pure C coroutine The Fiber proposal never mentions the support for pure C coroutines. In = Swow, the event scheduler is a pure C function and does not need a PHP = stack. It only needs to switch the C stack when switching to other = coroutines and its switching performance is almost double that of PHP, = because, in such a coroutine system, most exchanges occur between the = scheduler and other coroutines. 5. Not compatible with Swoole In my opinion, Swoole is an important part of the PHP ecosystem. But = now, Fiber cannot work with Swoole. And based on the above reasons, = Swoole will not consider compatible fiber. We would expect some ZendAPI rather than Fiber extensions to provide = support for coroutine switching. 6. Boost-context is not used on the Windows The performance of win-fiber is far inferior to boost-context. I can not = find any reason to use win-fiber instead of boost-context in Windows. The Swow extension uses boost-context on all platforms and has been = actively tested (https://github.com/swow/swow/runs/2053921797). CI will = also automate execute nightly build and release DLL = (https://github.com/swow/swow/releases), and there is no issue so far. Also, there are many fragmentary issues. Due to limited time, I cannot = write them all at once. Of course, some designs of ext-fiber still refresh me, such as using = Reflection to get coroutine status (in Swoole, we just keep adding = methods to the coroutine class). Nevertheless, I don=E2=80=99t know what = the benefits of using Reflection to get these states are. I'm not particularly satisfied with all aspects of ext-fiber's overall = plan and C code implementation, so I have to point them out here. Regards, Twosee