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
