Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112542
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
In-Reply-To: <CAPrKfG5fQCb4MMHrZzsu2c8UJ+GGmsbM5eO90t4O-QTq5wTQOg@mail.gmail.com>
Date: Thu, 17 Dec 2020 13:43:36 -0600
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <461ED1D8-45CF-431C-91BA-959EF511CBBD@trowski.com>
References: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
 <CAPrKfG5fQCb4MMHrZzsu2c8UJ+GGmsbM5eO90t4O-QTq5wTQOg@mail.gmail.com>
To: Peter Stalman <sarkedev@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Fibers
From: aaron@trowski.com (Aaron Piotrowski)

Hi Peter,

> On Dec 17, 2020, at 1:23 PM, Peter Stalman <sarkedev@gmail.com> wrote:
>=20
> Hi Aaron, this is very interesting to me.  Can I ask why this approach =
as
> opposed to other paradigms like promises, coroutines, etc?  You =
mentioned
> async/await in the future scope, and I assume most of these patterns =
can be
> implemented once there is an underlying functionality.  Basically, why
> fibers instead of x?

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.

Fibers are a method of implementing coroutines or interruptible =
functions. Promises likely would still be used as placeholders in =
libraries using fibers, but coroutines written using fibers do not have =
to return another placeholder. Fibers allow async code to be =
indistinguishable from sync code, as opposed to an approach where async =
functions must return a promise.

>=20
> You also mentioned this isn't really intended to be used directly, but =
with
> a library such as AMPHP.  IS the expectation that non-blocking I/O
> functionality like database drivers and file operation be provided by
> libraries as well?
>=20

Since most code written for PHP is blocking, yes, such =
libraries/frameworks would need to provide functionality such as =
database drivers. Both AMPHP and ReactPHP already have existing async =
drivers available for several different popular database systems. =
AMPHP=E2=80=99s postgres, mysql, and redis drivers already have a =
version using fibers.

> I hope I don't come off as critical, I am merely curious.  Thank you =
for
> pushing this forward, as async is something PHP has been lacking and =
should
> have IMO to compare favourably to other alternatives that do.
>=20

You didn=E2=80=99t com off as critical at all! These were good questions =
to ask. I too think if PHP is to add support for async code it should =
compare favorably to other languages. I think fibers offer a distinct =
advantage to using promise for async code.

Cheers,
Aaron Piotrowski=