# async/await - is future reserved words in PHP 7.x?

- Thread: https://externals.io/message/88558
- Original archive: https://news-web.php.net/php.internals/88558
- Started by Daniel Lowrey on 2015-09-29T16:15:43+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #88558 — Daniel Lowrey — 2015-09-29T16:15:43+00:00

URL: https://externals.io/message/88558#88558

> 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...> > -- > > >

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.

---

## #88592 — Stephen Coakley — 2015-10-01T06:29:48+00:00

URL: https://externals.io/message/88558#88592 · In reply to: #88558

> > […]
>
> 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

---

## #93066 — S.A.N — 2016-05-04T10:59:33+00:00

URL: https://externals.io/message/88558#93066 · In reply to: #88592

> 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`.
>
EventLoop interface, on development stage:
https://github.com/async-interop/event-loop

PHP wrappers for libev and libeio supported PHP 7.
https://pecl.php.net/package/ev
https://pecl.php.net/package/eio

libuv - certainly better because it has everything you need and a huge
community.

Very need async/await in the PHP core (based on generators).
Perhaps there are plans in core developers, for implement async/await?

---

## #93070 — Stephen Coakley — 2016-05-04T14:40:10+00:00

URL: https://externals.io/message/88558#93070 · In reply to: #93066

> EventLoop interface, on development stage:
> https://github.com/async-interop/event-loop

That's a userland design for event loops; async/await and coroutines 
don't necessarily depend on an event loop. They could be added to the 
language without an event loop, and simply require the user to provide 
the event loop.

My idea was to make a transition into async as simple as possible.

Also, I'm partially responsible for the event loop interface above. :P

> PHP wrappers for libev and libeio supported PHP 7.
> https://pecl.php.net/package/ev
> https://pecl.php.net/package/eio
 >
> libuv - certainly better because it has everything you need and a huge
> community.

I agree; libuv is probably the best of the bunch, if we include an event 
loop library in future versions of PHP. It is not necessary to have a 
PHP wrapper for libuv, since if it was included in the interpreter 
itself we would be just using the C interface.

> Very need async/await in the PHP core (based on generators).
> Perhaps there are plans in core developers, for implement async/await?

/Legend speaks of such plans, but they come and go in whispers. Like a 
shadow, or a mist from the east. The prophecy spake of such features 
targeting PHP8; lo, most believe it to be myth./

-- 
Stephen

---

## #93073 — Niklas Keller — 2016-05-04T16:44:46+00:00

URL: https://externals.io/message/88558#93073 · In reply to: #93070

2016-05-04 16:40 GMT+02:00 Stephen Coakley <me@stephencoakley.com>:

> 
>
> > […]
>
> That's a userland design for event loops; async/await and coroutines don't
> necessarily depend on an event loop. They could be added to the language
> without an event loop, and simply require the user to provide the event
> loop.
>

Would be strange to have async / await in the language without an event
loop, but it's possible, yes.


> My idea was to make a transition into async as simple as possible.
>
> Also, I'm partially responsible for the event loop interface above. :P
>
> PHP wrappers for libev and libeio supported PHP 7.
> > […]
>
> > […]
>
> I agree; libuv is probably the best of the bunch, if we include an event
> loop library in future versions of PHP. It is not necessary to have a PHP
> wrapper for libuv, since if it was included in the interpreter itself we
> would be just using the C interface.
>
> Very need async/await in the PHP core (based on generators).
> > […]
>
> /Legend speaks of such plans, but they come and go in whispers. Like a
> shadow, or a mist from the east. The prophecy spake of such features
> targeting PHP8; lo, most believe it to be myth./


Why do we have to wait until PHP 8? Should be mostly backwards compatible
and be fine in 7.2 or so. Issue is probably more deciding on an API.


>
> --
> Stephen

---

## #93074 — S.A.N — 2016-05-04T17:41:20+00:00

URL: https://externals.io/message/88558#93074 · In reply to: #93073

> > […]
>
>
> Why do we have to wait until PHP 8? Should be mostly backwards compatible
> and be fine in 7.2 or so. Issue is probably more deciding on an API.
>
>

Yes, I think so, too, do not need to wait for version 8, can start
7.1-2 possible even as another SAPI.

P.S.
These works will accelerate 5x-10x
https://gnugat.github.io/2016/04/13/super-speed-sf-react-php.html

---

## #93075 — Stephen Coakley — 2016-05-04T18:44:49+00:00

URL: https://externals.io/message/88558#93075 · In reply to: #93073

> 2016-05-04 16:40 GMT+02:00 Stephen Coakley <me@stephencoakley.com>:
> Why do we have to wait until PHP 8? Should be mostly backwards compatible
> and be fine in 7.2 or so. Issue is probably more deciding on an API.
>

I don't think we should wait, I was just thinking that it might not be 
ready until that time.

Also, if we plan on rewriting streams and I/O to all be async and use 
libuv underneath, that would probably be a BC break unless the existing 
functions just become blocking interfaces for a separate async API. If 
it was a large BC break, it probably would need to wait for PHP 8.

Now that I think about it, that would be our chance to replace stream 
resources with classes...

$file = \php\stream::open("file.txt");
$bytes = await $file->read(1024);
$file->close();

Then rewrite `fread()` and friends to be aliases that block instead of 
await results.

-- 
Stephen

---

## #93076 — S.A.N — 2016-05-04T19:56:30+00:00

URL: https://externals.io/message/88558#93076 · In reply to: #93075

> I don't think we should wait, I was just thinking that it might not be ready
> until that time.
>
> Also, if we plan on rewriting streams and I/O to all be async and use libuv
> underneath, that would probably be a BC break unless the existing functions
> just become blocking interfaces for a separate async API. If it was a large
> BC break, it probably would need to wait for PHP 8.
>
> Now that I think about it, that would be our chance to replace stream
> resources with classes...
>
> $file = \php\stream::open("file.txt");
> $bytes = await $file->read(1024);
> $file->close();
>
> Then rewrite `fread()` and friends to be aliases that block instead of await
> results.

This is a great opportunity to normalize API standard libraries PHP :)

> $bytes = await $file->read(1024);

It is rarely necessary, more often needs

$result = await $db->query($sql);
and
$result = await $noSql->get($key);