Thomas, On Tue, Sep 29, 2015 at 11: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.
Parallelism and concurrency are not the same thing. There are a ton of resources on this, but I'll point to two specifically, Rob Pike (from GoLang): https://www.youtube.com/watch?v=cN_DpYBzKso and Joe's own blog: http://blog.krakjoe.ninja/2015/07/the-universe-is-not-aware.html > Async/await is both the best of and THE solution to both worlds. A whole lot of people would argue that. It's not that it's not a good solution, but it's *A* solution. Each mechanism (event loops, threading, channels, compiler-driven-concurrency, etc) has its own pros and cons, and handle different situations better. A simple example is that raw threads can scale across CPUs, but event loops typically can't (since it's typically single threaded). That's not to say it's impossible to write a cross-CPU event loop, but that requires additional implementation/constraints. There are such non-trivial tradeoffs to each, that there's no clear "best" solution to any of it. Async/await is one way. Golang's channels are another subtly different yet very good way as well. Another even better way may be to take an approach which is to leave it to the compiler to figure out what can be made async (though that may not be strictly possible with PHP in most cases). Claiming that one technique is the victor, without explicitly stating the constraints that are required, is not a great idea. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
