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

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