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

On 09/29/2015 10:22 AM, Thomas Hruska 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 ...

Agreed, the concepts are quite different, thought they can be related in a way. More on that in a minute...

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

Actually, they *don't* attempt to solve the same problem (though some problems can be solved with either). Concurrent programming (threads, forks, or anything else that uses multiple execution contexts -- multiple program counters) has the purpose of enabling you to do two or more things at once (as much as possible on the current CPU). If you need to do two big ass math calculations, you can use multithreading to do both at once. (I'll ignore instruction pipelining restrictions and the context switching overhead curve for simplicity.) In this example, asynchronous programming does nothing for us. If you need to handle 10000 socket connections, threading isn't practical with a thread-per-connection model. Here, async becomes useful because the bottleneck is I/O, not CPU operations. Async programming allows you to do other things instead of blocking the thread when doing an I/O operation (... or a few other operation types). So then, in summary, threads & multiprocessing enables you to do more *work* simultaneously, while async **maximizes the usefulness of each thread you have**. So using both is actually an incredibly good thing, but they aren't the same nor accomplish the same thing. I hope what I said made sense. Now, on to async / await. :)

Async/await is both the best of and THE solution to both worlds. It ...

Yes. But not for the reason that I think you're thinking. Combining concurrency with asynchronicity is the best of both worlds, and using threads themselves in a non-blocking way with async / await (which are strictly an async thing) is pretty powerful. Here's an example (in .NET):

    static async void SlowAsync()
    {

// Create a task which will be run in the threadpool Task task = new Task(SlowAssOperation); // Asynchronously wait (using the .NET event loop) for the thread to complete await task;

    }

    static void SlowAssOperation()
    {

// Do something synchronous Thread.Sleep(5000);

    }

The fact that we can await something being run in a thread isn't a property of threads, but a property of the .NET async event loop which can listen for thread events without blocking. Hope that clears some things up. Sorry for being long winded. :) -- Stephen