Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102441 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35475 invoked from network); 25 Jun 2018 19:48:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jun 2018 19:48:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=aaron@trowski.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=aaron@trowski.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain trowski.com designates 199.38.81.6 as permitted sender) X-PHP-List-Original-Sender: aaron@trowski.com X-Host-Fingerprint: 199.38.81.6 mercury.negativeion.net Received: from [199.38.81.6] ([199.38.81.6:64974] helo=mercury.negativeion.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DB/AD-50433-927413B5 for ; Mon, 25 Jun 2018 15:48:58 -0400 Received: from localhost (localhost [127.0.0.1]) by mercury.negativeion.net (Postfix) with ESMTP id 65A0E20197F8DA; Mon, 25 Jun 2018 15:48:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at negativeion.net 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 fcJB6LzySuHP; Mon, 25 Jun 2018 15:48:54 -0400 (EDT) Received: from [10.0.1.2] (unknown [173.225.159.140]) by mercury.negativeion.net (Postfix) with ESMTPSA id 893D920197F8CC; Mon, 25 Jun 2018 15:48:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) In-Reply-To: Date: Mon, 25 Jun 2018 14:48:53 -0500 Cc: PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: <3202A491-F9BD-4049-B76B-550385038A77@trowski.com> References: To: Zeev Suraski X-Mailer: Apple Mail (2.3445.5.20) Subject: Re: [PHP-DEV] PHP 2^3 From: aaron@trowski.com (Aaron Piotrowski) > On Jun 25, 2018, at 7:30 AM, Zeev Suraski wrote: >=20 >=20 > 2. Better support long-running, async-based, microservices-focused = execution model. It's probably no secret that one of the key reasons = Node is gaining popularity is because it can handle a huge number of = concurrent connections issuing relatively lightweight requests very = efficiently - which is a good match for modern microservices based = architectures. There are already several projects available for PHP = that aim to provide similar functionality - most notably ReactPHP and = more recently Swoole. > The main thing that is missing is that most of PHP's IO doesn't = support async execution. What I think we should do is add as much = support for async IO as possible across the various extensions and = streams - so that using something like Swoole would become practical for = more use cases. More specifically - the goal would be to provide = extension authors with mechanisms that they can use to make their = extensions/functions optionally asynchronous, without having to tackle = the job entirely on their own. While we've done some research into this = area, it requires a lot more research - but I'm cautiously optimistic = that it can be done. We would potentially want to use libuv for this = task, and potentially rewrite or otherwise refactor parts of the PHP = streams system. >=20 Regarding async, are you referring to the Fiber extension? In my = opinion, fibers would be the best approach for async in PHP. After using = async/await in other languages, it doesn't offer a significant gain over = what's already possible in PHP with generator-based coroutines in Amp. = Using the fiber extension and a green-thread library that resumes fibers = based on promise resolution [1], we've been able to write async code = without the need for yield or await [2], with async functions having = proper return types (i.e. not promise, but the type the promise would = resolve to). Joel Wurtz has also put together a PoC of using Doctrine = asynchronously using the fiber extension and Amp [3]. A new major may not be strictly necessary to introduce this feature, but = it would ease introducing new keywords for awaiting IO and = "promisifying" a function using fibers to allow simultaneous IO. These = keywords could be async and await, though they would be used differently = than JavaScript or other languages. See an example in the green-thread = library [4], where the await() function uses Fiber::yield() to wait for = promise resolution, and async() creates a promise from a function using = await(). I would propose using keywords in place of these two functions. I successfully am using Amp's http-server library with several other Amp = libraries to run a website using long-running processes under PHP 7.2. = I've seen no issues with memory leaks, crashing processes, or other = unexpected behaviors. I think PHP is absolutely ready to shine in = environments outside of per-request SAPIs. Core support for async is one = of the few ingredients missing. Aaron Piotrowski [1] https://github.com/amphp/green-thread [2] https://github.com/amphp/byte-stream/tree/ext-fiber [3] https://github.com/joelwurtz/doctrine-async [4] = https://github.com/amphp/green-thread/blob/e13327a84be67d289aec87984f9d5c8= e1fddd471/examples/simultaneous-async.php