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

Hi Thomas, > On Sep 29, 2015, at 10:22 AM, Thomas Hruska <thruska@cubiclesoft.com> wrote: > > On 9/29/2015 6:52 AM, Joe Watkins wrote: >> We shouldn't reserve words on a whim ... >> >> async/await doesn't solve any problems for multithreaded programming, at >> all ... it solves problems for asynchronous programming, a different >> concept ... let's not confuse the two ... > > Actually, it does. Asynchronous and multithreaded programming are attempts at solving the > exact same problem: Simultaneously handling multiple data streams in whatever form that takes > whether that be network, hard drive, random device XYZ, RAM, or even CPU. The former says, > "Let's wait until we can read or write and continue when we have data." The latter > says, "Let's read and write but let the OS handle context switching to give the appearance > of simultaneously handling multiple data streams." > > Async/await is both the best of and THE solution to both worlds. It allows, on a single > thread, multiple functions to be executed simultaneously, resuming each function exactly where it > left off when the async call "returns" to the await. This feature results in *elegant > userland code* that never unexpectedly blocks, transparently fires up threads wherever necessary, > maintains mapped pools of handles behind the scenes, and resumes functions where they left off on > the original thread. There is no other equivalent model today that doesn't involve tons of > error-prone plumbing. Also, with today's error-prone models, portions of async/await actually > can't be implemented without resorting to questionable assembler hacks (hello 1980's!). > As I said earlier, async/await is the single greatest solution to multithreading (because very > little code actually needs multiple threads in an async/await world) but it also dramatically > simplifies asynchronous programming. Async/await also can't be implemented in libraries - it > has to be implemented in the core of the language itself and therein lies both the genius for > userland code (thank you Microsoft!) as well as the horribleness for language designers (thank you > Microsoft?). Everyone who writes "userland code" in any given language wants this, but no > one ever wants to be responsible for correctly implementing this feature because there is much evil > hackery required to pull it off. > > For the most part, PHP follows a single-threaded, synchronous/sometimes asynchronous model, > which works well for web, and therefore means users can somewhat fake async/await with > promises/futures and no one there will really notice because no one there will really use either > feature. However, the single-threaded model doesn't necessarily apply to CLI where some of the > real power of PHP can be leveraged - with long-running processes, unlimited CPU, and fewer RAM > limitations, a lot of possibilities open up. > > So the underlying question really is: Is PHP, particularly CLI, ever going to leave its > single-threaded model? If not, then this discussion dies here. But if so, then async/await is the > most desirable solution, albeit being extremely evil and difficult to implement. > > https://channel9.msdn.com/Events/Build/2012/3-011 > > -- > Thomas Hruska > CubicleSoft President > > I've got great, time saving software that you will find useful. > > http://cubiclesoft.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Asynchronous programs do not solve the same problem as multithreading. Asynchronous programs cannot execute code in parallel like a multithreaded program. Asynchronous code relies on non-blocking I/O to continuously execute available tasks in a single thread of execution, but only one function is ever being executed at a time within that thread. Often separate threads are used to implement non-blocking I/O or other tasks. Asynchronous coding is a complement to multithreading, not a replacement. Implementing elegant, readable, and stable asynchronous code in userland PHP code is very possible. In fact, I’ve done exactly this with Icicle (https://github.com/icicleio/icicle). Icicle uses generators and promises to implement coroutines. When a coroutine yields a promise, the coroutine is interrupted until the promise resolves, sending or throwing the resolution value into the generator. While a coroutine is interrupted, other code in the program is given the chance to be executed. This behavior is similar to async/await, instead using a generator as the async function and yield as await. There are several packages available for Icicle that implement non-blocking I/O and concurrency (multithreading). There are no extensions required for Icicle and no black magic – just making good use of the tools already available. Regards, Aaron Piotrowski