Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113597
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>
In-Reply-To: <CAKiSzdCPPM-s7yA75dJqS7N4j-VQHCfuXc5K6Zrh+sm_bdSUHQ@mail.gmail.com>
Date: Wed, 17 Mar 2021 19:43:28 -0700
Message-ID: <CAPrKfG6hbu2K1ans4+a2ajm1TCBCM+TZSr4ESBXj9BHH3gaiCQ@mail.gmail.com>
To: Josh Di Fabio <joshdifabio@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000022b33605bdc69151"
Subject: Re: [PHP-DEV] [VOTE] Fibers
From: sarkedev@gmail.com (Peter Stalman)

--00000000000022b33605bdc69151
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 17, 2021 at 7:41 AM Josh Di Fabio <joshdifabio@gmail.com> wrote:

> 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 the
race condition caused by async, and the other is if the top level code
explicitly states that it is called asynchronously.

When I used the Guzzle `requestAsync()` example, it was meant to show that
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
`setTransactionId()` 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 without 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
inside 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
calls.  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
`yield` keyword in front of them, the developer cannot be unaware that they
are inside an event loop that can resume fibers.

I am arguing against you saying this RFC is "very dangerous", because this
feature can only be dangerous if you use it.  It's like saying `exec()` is
very dangerous, because you can screw up all sorts of things with it.  But
it is only dangerous if you use it without knowing what you are doing.

Thanks,
Peter

--00000000000022b33605bdc69151--