Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113579
MIME-Version: 1.0
References: <D376DEFE-26A4-4F11-8548-D9454087E9FD@trowski.com>
 <70951423-5e77-c150-6dce-dd3c62f8dc8b@php.net> <0b994a60-7970-605b-1657-d6ee732690e5@gmx.de>
 <5C73A1DE-E563-4F69-B8C7-6506F81D7345@trowski.com> <CAKiSzdDVR+joZQQtAS03rAZE_HBZir1CkaBG-BJm6Da1xLnu6A@mail.gmail.com>
 <CANUQDCg-TQCC6LBhDBRvXse2CpVODmM5cK5==a-yMOS09VYeGg@mail.gmail.com>
 <CAKiSzdA+6YK69ez_9kZGACTNMi_e44xX_UPLfDCoU1i0qrF-ew@mail.gmail.com> <cc0e0683-2dda-4340-a3b0-6e601882a65f@www.fastmail.com>
In-Reply-To: <cc0e0683-2dda-4340-a3b0-6e601882a65f@www.fastmail.com>
Date: Tue, 16 Mar 2021 20:57:43 +0000
Message-ID: <CAKiSzdCzXkx_e2ZSbFRFNCd_9F-N_ZZ3-qDMxVZt-jOMMuyVuA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Fibers
From: joshdifabio@gmail.com (Josh Di Fabio)

Hi Larry,

Thanks for the feedback. Replies inline.

On Tue, Mar 16, 2021 at 8:33 PM Larry Garfield <larry@garfieldtech.com> wro=
te:
>
> On Tue, Mar 16, 2021, at 1:44 PM, Josh Di Fabio wrote:
>
> > Perhaps we could rather make fibers *opt in* at the *callsite*
> > (similar to goroutine calls) in order to prevent functions
> > unexpectedly being executed asynchronously due to faraway changes.
> > This would be safe and predictable while also avoiding the "What color
> > is your function" problem. For example
> >
> >     private function capturePayment(): void
> >     {
> >         $paymentRequest =3D preparePaymentRequest($this->currentOrder);
> >         // allow, but don't require, the underlying call to use
> > fibers. Callers higher up the stack would also have to opt in
> >         async $this->paymentGateway->capturePayment($paymentRequest);
> >
> > $this->currentOrder->setTransactionId($paymentRequest->getTransactionId=
());
> >     }
> >
> > With this approach, APIs we'd avoid the "what colour is your function"
> > problem without sacrificing the safety that we really need in e.g.
> > ecommerce.
>
> "Callers higher up the stack would also have to opt in" is precisely and =
specifically the design flaw that fibers avoid.

What you are calling a design flaw, is by far the most common approach
to async in other languages.

> What you're suggesting is that a given IO call would become magically non=
-blocking iff its entire parent call stack was called with `async` keywords=
, which could be 50 stack frames easily. Aside from the implementation chal=
lenge, and the fact that it would require two different code paths even in =
the PHP code around that IO ...

This is already the case with the fiber RFC as it stands. If you are
not within fiber context, then calls to fiber-enabled are sync. If you
are within fiber context, they're async.

> ... event if it could be implemented it would mean that basically no IO c=
ode would ever run async, ever, because there is one function call somewher=
e in the stack that didn't include `async` in some library that everyone us=
es but hasn't been updated to prefix every single function call with `async=
`.

This is very close to how goroutines work in Golang.

> That is literally the "What color is your function" problem.

Some of the "problems" are still present, but I am still suggesting
that there be only one implementation of each function, rather than
two, and that implementation can be called from either a synchronous
or asynchronous context.

> I should also note that if you are following good practices to begin with=
, your code base is 90% pure, immutable functions/methods and so entirely s=
afe from cooperative multitasking race conditions.

Right, but that code should generally be synchronous, because if a
function is async then it's doing IO and isn't a pure function. But
note that as this RFC stands there's no way to know that without
actually reading all the code. Perhaps you are rather talking about
side effects, it's unclear.

> If that's not the case, you have a buggy codebase already even without fi=
bers.  Fibers would just make it more obvious.

Fibers will not make those issues obvious at all. The issues I'm
describing will only crop up spontaneously and under load.

> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Cheers