Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88558
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.181 as permitted sender)
MIME-Version: 1.0
Sender: rdlowrey@gmail.com
Date: Tue, 29 Sep 2015 12:15:43 -0400
Message-ID: <CAH8Mpn=qHqqQsoMusw0WJG2UGiQ7g43_a7gpG=Bcy0LGSpjyUg@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bd6be0e3395420520e520c8
Subject: Re: async/await - is future reserved words in PHP 7.x?
From: rdlowrey@php.net (Daniel Lowrey)

--047d7bd6be0e3395420520e520c8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> On Sep 28, 2015, at 3:29 AM, S.A.N <ua.san.alex@gmail.com> wrote:> > Are =
there any future plans for - async/await?> This need to know now, not to us=
e these words to constants, and class names...> > -- > PHP Internals - PHP =
Runtime Development Mailing List> To unsubscribe, visit: http://www.php.net=
/unsub.php>

Would this be awesome? Yes. The issue is that all of PHP's built-in IO
operations are currently synchronous. It would/will require a massive
effort to (1) install the infrastructure to offload blocking operations to
worker threads and/or (2) convert many synchronous IO operations to a
non-blocking paradigm. Someone has to do that work ... and it's a lot. I
don't personally see this happening before 8.0 though I'd be happy to be
surprised.

FWIW I'm a big proponent of libuv here and think we could significantly
improve PHP as a language by incorporating it to solve this (and other)
outstanding issues in a cross-OS manner.

In the nearer term, this is exactly the sort of thing the Generator Return
and Generator Delegation RFCs implemented in 7.0 are designed to handle.
With a minimal amount of userland code you can resolve coroutines in
userland as lightweight threads in which IO is accomplished with
non-blocking libraries.

The obvious drawbacks to using yield in userland as a surrogate for
async/await is the proliferation of non-standard userland libraries (of
which several good options already exist) to manage IO, timers and event
loops.

IMHO userland shouldn't know anything about *how* concurrency is achieved
(whether using threads or nbio). With something like libuv internal C code
would have access to a built-in worker thread pool designed specifically
for a non-blocking paradigm. This would allow us to expose the best of both
worlds.

Just my $0.02 on the topic.

--047d7bd6be0e3395420520e520c8--