Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113495 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98933 invoked from network); 12 Mar 2021 17:42:02 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Mar 2021 17:42:02 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 59107180087 for ; Fri, 12 Mar 2021 09:34:50 -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=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mercury.negativeion.net (mercury.negativeion.net [199.38.81.6]) by php-smtp4.php.net (Postfix) with ESMTP for ; Fri, 12 Mar 2021 09:34:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.negativeion.net (Postfix) with ESMTP id 5567420CC43E03; Fri, 12 Mar 2021 12:34:49 -0500 (EST) Received: from mercury.negativeion.net ([127.0.0.1]) by localhost (mercury.negativeion.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssLv4hy92AO1; Fri, 12 Mar 2021 12:34:48 -0500 (EST) Received: from [10.0.1.101] (unknown [173.225.146.47]) by mercury.negativeion.net (Postfix) with ESMTPSA id 7E46420CC43DF2; Fri, 12 Mar 2021 12:34:48 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) In-Reply-To: Date: Fri, 12 Mar 2021 11:34:47 -0600 Cc: Dan Ackroyd , =?utf-8?B?6Z+p5aSp5bOw?= , php internals Content-Transfer-Encoding: quoted-printable Message-ID: <41D9E769-39EE-4CB0-9A99-FD295893AD0E@trowski.com> References: <8812EE70-4720-4639-926E-1EA206624BC1@trowski.com> To: twosee X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [PHP-DEV] [VOTE] Fibers From: aaron@trowski.com (Aaron Piotrowski) > On Mar 12, 2021, at 3:00 AM, twosee wrote: >=20 > 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. >=20 > 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. >=20 > Generally, the solution provided by Swow is completely a superset of = Fiber. >=20 Hi Twosee, I wanted to address the point above from your email. I do not think = auto-magically altering the behavior of existing functions to use async = I/O is a good idea. Existing code that relies on a constant state during = an I/O operation that previously was blocking may no longer work as = expected. Changing behavior is a major BC break. It would be better to = introduce new async versions of functions, e.g., asio_fwrite(), instead = of altering the existing fwrite() function. This way libraries which = have interfaces requiring blocking I/O, such as libraries implementing = PSR-7/15, can create versions that are designed with async I/O in mind, = while keeping existing implementations working as expected. Changing the behavior of existing functions reminds me of the = `mbstring.func_overload` feature that is now deprecated because of the = compatibility problems it caused. I took a look at Swow this morning. Again, I would compare Swow to = Swoole =E2=80=93 it is another large, opinionated framework for = asynchronous PHP apps. Swow is not a lightweight, standalone feature = that can be merged into PHP at one time. The Fiber API is small in scope = and does not alter existing behaviors. Looking at the fiber implementation in Swow, I see it uses the same = boost library and the same asymmetric coroutine model as ext-fiber. It = seems Swow could use an internal API provided by PHP for fibers, = allowing it to drop the boost dependency. This leads me to believe my proposal would be mutually beneficial to = both your extension and the wider PHP community that could use fibers = outside of your framework or Swoole. Cheers, Aaron Piotrowski=