Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88592
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <18.B0.04700.FD2DC065@pb1.pair.com>
To: internals@lists.php.net
References: <CAH8Mpn=qHqqQsoMusw0WJG2UGiQ7g43_a7gpG=Bcy0LGSpjyUg@mail.gmail.com>
Date: Thu, 1 Oct 2015 01:29:48 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAH8Mpn=qHqqQsoMusw0WJG2UGiQ7g43_a7gpG=Bcy0LGSpjyUg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: async/await - is future reserved words in PHP 7.x?
From: me@stephencoakley.com (Stephen Coakley)

On 09/29/2015 11:15 AM, Daniel Lowrey wrote:
>> 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 use 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.
>

I think we can spoonfeed the massive undertaking a bit by spreading it 
across several iterations just to get things going. An idea I had was to 
just begin by providing coroutines as part of the language. That would 
include a `\Coroutine` class, as well as await / async keywords. This 
would at least enable third party async libraries to be more compatible 
since they would have the same await types and semantics.

The next step (or at the same time as the first) is to provide some sort 
of `\EventLoopInterface` along with

     \EventLoop::getLoop(): \EventLoopInterface
     \EventLoop::setLoop(\EventLoopInterface)
     \EventLoop::run()
     \EventLoop::stop()
     \EventLoop::tick()

To start out, just provide the internal coroutine scheduler as a default 
implementation. Coroutines would use the "event loop" to schedule resumes.

Doing so would allow even more interoperability if a library chose to 
implement `\EventLoopInterface` in its event loop, where it handles 
coroutine scheduling (or lets it fall back to the internal one), and 
could also provide I/O "extras".

The final step would be to bring libuv into PHP, itself as a better 
default implementation of `\EventLoopInterface`.

Just my idea.

-- 
Stephen