Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88559
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain icicle.io designates 199.38.81.6 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <560AACB6.9080909@cubiclesoft.com>
Date: Tue, 29 Sep 2015 11:16:24 -0500
Cc: Joe Watkins <pthreads@pthreads.org>,
 =?utf-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>,
 Kalle Sommer Nielsen <kalle@php.net>,
 Pierre Joye <pierre.php@gmail.com>,
 Levi Morrison <levim@php.net>,
 PHP internals <internals@lists.php.net>,
 "S.A.N" <ua.san.alex@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <09A2B2D4-EAE9-46E8-AF5C-4E83C4F3D8A2@icicle.io>
References: <CALW=WEBPC2N2tzmU1uB_v93YXLa1MA97=0_q7zP0F6G+uRPDNQ@mail.gmail.com> <56095A0C.4070306@cubiclesoft.com> <CAFMT4NqaqVX-KHh9iz_R05wxp2h=aajv5RuQGh2EQVSNHoLGaQ@mail.gmail.com> <CAEZPtU6cgVrqh0PNYybcrk4_X36m5K=dp280G=7OfzjYBzxJpQ@mail.gmail.com> <CAJW__o2727mc+ugUd2NvvYTB-r0dC68dkUOke+oPjwZDtZA+vQ@mail.gmail.com> <1443529244.15520.67.camel@kuechenschabe> <CAL=_i_kXeBiQ4O9u-0mXu47zKt2-c9uQSWGZ4KReTfjzbzT7kw@mail.gmail.com> <560AACB6.9080909@cubiclesoft.com>
To: Thomas Hruska <thruska@cubiclesoft.com>
Subject: Re: [PHP-DEV] async/await - is future reserved words in PHP 7.x?
From: aaron@icicle.io (Aaron Piotrowski)

Hi Thomas,

> On Sep 29, 2015, at 10:22 AM, Thomas Hruska <thruska@cubiclesoft.com> =
wrote:
>=20
> On 9/29/2015 6:52 AM, Joe Watkins wrote:
>> We shouldn't reserve words on a whim ...
>>=20
>> 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 ...
>=20
> 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."
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> https://channel9.msdn.com/Events/Build/2012/3-011
>=20
> --=20
> Thomas Hruska
> CubicleSoft President
>=20
> I've got great, time saving software that you will find useful.
>=20
> http://cubiclesoft.com/
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

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=E2=80=99ve 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 =E2=80=93 just making good use of the tools =
already available.

Regards,
Aaron Piotrowski