Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102469
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 85.215.255.24 cause and error)
MIME-Version: 1.0
References: <9f5698a2-aef7-4bea-99a4-cd8b22c49150@email.android.com>
In-Reply-To: <9f5698a2-aef7-4bea-99a4-cd8b22c49150@email.android.com>
Date: Tue, 26 Jun 2018 22:36:07 +0200
Message-ID: <CANUQDCgZUiezDTOegMU-W8py11c-QswrG4FKVCCjqsU2z1G_cA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Aaron Piotrowski <aaron@trowski.com>, Zeev Suraski <zeev@zend.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 2^3
From: me@kelunik.com (Niklas Keller)

Hey Dmitry,

>
> hi Aaron,
>
>
> On Jun 25, 2018 10:49 PM, Aaron Piotrowski <aaron@trowski.com> wrote:
>
> > On Jun 25, 2018, at 7:30 AM, Zeev Suraski <zeev@zend.com> wrote:
> >
> >
> > 2. Better support long-running, async-based, microservices-focused exec=
ution model.  It's probably no secret that one of the key reasons Node is g=
aining popularity is because it can handle a huge number of concurrent conn=
ections issuing relatively lightweight requests very efficiently - which is=
 a good match for modern microservices based architectures.  There are alre=
ady several projects available for PHP that aim to provide similar function=
ality - 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 asy=
nc IO as possible across the various extensions and streams - so that using=
 something like Swoole would become practical for more use cases.  More spe=
cifically - the goal would be to provide extension authors with mechanisms =
that they can use to make their extensions/functions optionally asynchronou=
s, without having to tackle the job entirely on their own.  While we've don=
e some research into this area, it requires a lot more research - but I'm c=
autiously optimistic that it can be done.  We would potentially want to use=
 libuv for this task, and potentially rewrite or otherwise refactor parts o=
f the PHP streams system.
> >
>
> 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/awai=
t in other languages, it doesn't offer a significant gain over what's alrea=
dy possible in PHP with generator-based coroutines in Amp. Using the fiber =
extension and a green-thread library that resumes fibers based on promise r=
esolution [1], we've been able to write async code without the need for yie=
ld 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 pu=
t together a PoC of using Doctrine asynchronously using the fiber extension=
 and Amp [3].
>
> Febers/couroutines is one of the goals.
> Another possible goal =E2=80=94 event-loop primitives for internal extens=
ions (e.g. async DB queries)
> I think, we don't need async/await keywords or promises implementation in=
 core
> Anyway, as an expert in async PHP, you should tell us, what you really ne=
ed from the PHP core...
> I would be glad to hear your oppinion.
>
> Thanks. Dmitry.

Fibers are the major feature we're looking forward to, because it
allows async I/O in places that do not account for async, e.g. also
re-using interfaces designed for sync applications. Apart from that,
we want to avoid the boilerplate we currently have to write, i.e.
Amp\call wrapping a generator function.

We think that a methodless "Promise" / "Awaitable" type + fibers
implemented with keywords are the preferred way over the current Fiber
draft in the long run.

Fibers allow for transparent async I/O, which means we could maybe
transparently upgrade file_get_contents and others to use async I/O in
future versions, but something like that obviously needs an event-loop
in core.

That said, it's definitely something we want to push to PHP 8, but
nothing that has to be discussed in too much detail in this thread.

Regards, Niklas