Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113598
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> <CAKiSzdCzXkx_e2ZSbFRFNCd_9F-N_ZZ3-qDMxVZt-jOMMuyVuA@mail.gmail.com>
 <CAPrKfG5ZoiC02RdgNSP294OFq=kDBDPPOpmN7UTDKhzQah0GhA@mail.gmail.com>
 <CAKiSzdAXXX6d=tSyskbM5R3jc8-BQSYpT0g8TQPLpGDtuL+Sgw@mail.gmail.com>
 <CAPrKfG79Y4=SVFDFipXBpaEh+o_-kgQ38-=evR4GvgKZaOSmRw@mail.gmail.com>
 <CAKiSzdCPPM-s7yA75dJqS7N4j-VQHCfuXc5K6Zrh+sm_bdSUHQ@mail.gmail.com> <CAPrKfG6hbu2K1ans4+a2ajm1TCBCM+TZSr4ESBXj9BHH3gaiCQ@mail.gmail.com>
In-Reply-To: <CAPrKfG6hbu2K1ans4+a2ajm1TCBCM+TZSr4ESBXj9BHH3gaiCQ@mail.gmail.com>
Date: Thu, 18 Mar 2021 09:20:08 +0000
Message-ID: <CAKiSzdBHotq1qMYmOoZek7=URpVJT528FtZVxCQhuu3J5fEkdg@mail.gmail.com>
To: Peter Stalman <sarkedev@gmail.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 Peter,

Thanks for clarifying.

On Thu, Mar 18, 2021 at 2:43 AM Peter Stalman <sarkedev@gmail.com> wrote:
>
> On Wed, Mar 17, 2021 at 7:41 AM Josh Di Fabio <joshdifabio@gmail.com> wro=
te:
>>
>> Note the difference between the two. Also note how, in both of the
>> above cases, the asynchronicity is explicit and the developer has
>> opted into it. Both of the above are different approaches to that
>> being proposed in this RFC (this is a design choice by the authors).
>
>
> Hi again Josh,
>
> I think we are jumping back and forth on two different things.  One is th=
e race condition caused by async, and the other is if the top level code ex=
plicitly states that it is called asynchronously.
>
> When I used the Guzzle `requestAsync()` example, it was meant to show tha=
t you can have a library do something, and then continue execution like it =
had completed when in fact it had not.  This could cause your `setTransacti=
onId()` to happen before the `capturePayment()` request has completed, and =
in that regard it can be the same; not by how it works, but in concept.  I =
do know that they are different in implementation.  It would cause this wit=
hout an explicit keyword showing that `capturePayment()` used an async call=
 internally.  That is what I was referring to when I said it could also be =
a race condition now, without fibers.
>
> As I was also explaining earlier, the developer must know that they are i=
nside an async environment, because you can't suspend the main "thread".  `=
Fiber::suspend()` only works inside of a fiber, and for that to happen you =
must have run it inside of a framework that can schedule and resume these c=
alls.  To reiterate my earlier point, the average PHP developer will not be=
 in a place where this would ever occur out of the blue for them.  It's not=
 going to surprise them, and even though it might not have an `await` or `y=
ield` keyword in front of them, the developer cannot be unaware that they a=
re inside an event loop that can resume fibers.
>
> I am arguing against you saying this RFC is "very dangerous", because thi=
s feature can only be dangerous if you use it.  It's like saying `exec()` i=
s very dangerous, because you can screw up all sorts of things with it.  Bu=
t it is only dangerous if you use it without knowing what you are doing.
>
> Thanks,
> Peter
>
>

I understand your view; it's the same view that others have expressed
here including the RFC authors. I believe it is fair to paraphrase as,
"If you want to enable fibers in your application, you must be
confident about the implementation details of all of the code in your
application, including that of your dependencies, which are written
and maintained by other developers."

I don't have anything to add to my previous point in that I disagree
that this is practical.

Thanks