Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102441
Return-Path: <aaron@trowski.com>
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 <internals@lists.php.net>; 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: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
Date: Mon, 25 Jun 2018 14:48:53 -0500
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3202A491-F9BD-4049-B76B-550385038A77@trowski.com>
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
To: Zeev Suraski <zeev@zend.com>
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 <zeev@zend.com> 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