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

Thomas,

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

Hi Thomas,

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/

--

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

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

That description may have held a few years ago, when processes and threads were nearly always time-slices on a single CPU core, but surely on a modern system there can be real simultaneity, because even the cheapest laptop has multiple CPU cores. An asynchronous approach is useful for cases of "do something else while I wait for this background task to complete", but seems less so for "do both of these things actively, using whatever resource is available".

It may be that the first class of problem is more common, but that doesn't make the two equivalent.

Regards,

Rowan Collins
[IMSoP]

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