Hi Thomas, > On Sep 29, 2015, at 10:22 AM, Thomas Hruska <thru...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
