Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112546
Return-Path: <aaron@trowski.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 59050 invoked from network); 18 Dec 2020 06:37:43 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 18 Dec 2020 06:37:43 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 1A1DF1804D8
	for <internals@lists.php.net>; Thu, 17 Dec 2020 22:09:20 -0800 (PST)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE,
	SPF_PASS autolearn=no autolearn_force=no version=3.4.2
X-Spam-Virus: No
X-Envelope-From: <aaron@trowski.com>
Received: from mercury.negativeion.net (mercury.negativeion.net [199.38.81.6])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Thu, 17 Dec 2020 22:09:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
	by mercury.negativeion.net (Postfix) with ESMTP id 51A3820BA94778;
	Fri, 18 Dec 2020 01:09:18 -0500 (EST)
X-Virus-Scanned: amavisd-new at negativeion.net
Received: from mercury.negativeion.net ([127.0.0.1])
	by localhost (mercury.negativeion.net [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id lOEtCxbyP_7M; Fri, 18 Dec 2020 01:09:10 -0500 (EST)
Received: from [10.0.1.102] (unknown [173.225.146.47])
	by mercury.negativeion.net (Postfix) with ESMTPSA id 0944720BA941D9;
	Fri, 18 Dec 2020 00:59:53 -0500 (EST)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <36R8Ctg6RdOm8Ohh6Q_OZx0JNET8P_tTkbP03GbYuww57333-a1Zbn35nJmqIgwn3RLwRBwKESMdJX_bDsp9WEc2JEvyWS5hlwOb2qgkKt8=@protonmail.com>
Date: Thu, 17 Dec 2020 23:59:12 -0600
Cc: Peter Stalman <sarkedev@gmail.com>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <B286A549-3911-4AFE-9FD6-D935A6F5A385@trowski.com>
References: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
 <CAPrKfG5fQCb4MMHrZzsu2c8UJ+GGmsbM5eO90t4O-QTq5wTQOg@mail.gmail.com>
 <461ED1D8-45CF-431C-91BA-959EF511CBBD@trowski.com>
 <36R8Ctg6RdOm8Ohh6Q_OZx0JNET8P_tTkbP03GbYuww57333-a1Zbn35nJmqIgwn3RLwRBwKESMdJX_bDsp9WEc2JEvyWS5hlwOb2qgkKt8=@protonmail.com>
To: Saif Eddin Gmati <azjezz@protonmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Subject: Re: [PHP-DEV] [RFC] Fibers
From: aaron@trowski.com (Aaron Piotrowski)


> On Dec 17, 2020, at 4:11 PM, Saif Eddin Gmati <azjezz@protonmail.com> =
wrote:
>=20
> Hello Aaron,
>=20
> First, I want to say that I love this proposal and would love to see =
it land in the next PHP release, but I have one question regarding this:
>=20
>=20
>> Promises result in the =E2=80=9CWhat color is your function=E2=80=9D =
problem as described in the introduction of the RFC. Returning promises =
from functions means that functions calling those functions must also =
return promises, resulting in the entire call stack needing to return =
promises.
>=20
> Hack-Lang provides `HH\Asio\join` function which allows awaiting =
Awaitables in sync code, so you are capable of running multiple async =
tasks concurrently without having to declare the entire call stack as =
"async" or with an "Awaitable" return type, isn't this possible?
>=20
> ```
> use namespace HH\Asio;
>=20
> async function async_task(): Awaitable<void> {
>  await Asio\usleep(1000000);
> }
>=20
> <<__EntryPoint>>
> function main(): void {
>  $start =3D microtime(true);
>=20
>  $async =3D async {
>    concurrent {
>      await async_task();
>      await async_task();
>    };
>=20
>    return 'hello';
>  };
>=20
>  $result =3D Asio\join($async);
>=20
>  printf('Result: %s ( %f )', $result, microtime(true) - $start); // =
output "Result: hello ( 1.010382 )"
> }
>=20
> ```
>=20
> Regards,
>=20
> Saif.
>=20


Hi Saif,

`HH\Asio\join()` implements a synchronous await (I don't know the =
details of how its implemented, possibly involving entering and exiting =
the built-in event loop), but it does not solve the problem that =
functions using `await` need to be declared using `async` and return an =
Awaitable. Your example declares `async_task()` as async, while a =
similar function using the proposed fiber API would not need to change =
the function declaration to use `Fiber::suspend()`. There's an example =
in the RFC using `Amp\delay()` that is very similar to your code sample.

Fibers allow existing interfaces to be implemented using either sync or =
async I/O because the interface does not need to change to return =
promises/awaitables.

Cheers,
Aaron Piotrowski