Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113585
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>
In-Reply-To: <CAPrKfG5ZoiC02RdgNSP294OFq=kDBDPPOpmN7UTDKhzQah0GhA@mail.gmail.com>
Date: Wed, 17 Mar 2021 06:49:22 +0000
Message-ID: <CAKiSzdAXXX6d=tSyskbM5R3jc8-BQSYpT0g8TQPLpGDtuL+Sgw@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 the feedback!

On Wed, Mar 17, 2021 at 3:02 AM Peter Stalman <sarkedev@gmail.com> wrote:
>
> On Tue., Mar. 16, 2021, 13:58 Josh Di Fabio, <joshdifabio@gmail.com> wrot=
e:
>>
>> Fibers will not make those issues obvious at all. The issues I'm
>> describing will only crop up spontaneously and under load.
>
>
> Hi Josh,
>
> Is this really that big of a concern though?  The issue will only be a pr=
oblem if it's run inside an event loop/scheduler that the concerned library=
 is compatible with.  In which case the developer should be well aware of w=
hat is involved.

Not exactly, no. As a library author, code you wrote without fibers in
mind can become async.

Imagine for a moment that you create a library, awesome-library-x,
which uses a PSR logger internally. You will most certainly allow that
logger to be injected into your library. Now imagine that some other
developer uses awesome-library-x in their application, and injects it
with a monolog logger that logs to some AWS service via the AWS SDK.
In turn, that logger indirectly uses Guzzle, which adds fiber support.
As a result, any functions in awesome-library-x which log something
become asynchronous. Two changes made by two developers unrelated to
awesome-library-x cause its code to be executed asynchronously.

> Otherwise, if the library uses fibers internally it will have to resolve =
them itself before continuing, no?  If `capturePayment()` starts a fiber th=
en execution will not get to `setTransactionId()`, until it completed or is=
 handed of to a scheduler (again, which the developer would be aware of.
>
> So I don't think developers will face this race condition, unless they ar=
e using framework like amphp and reactphp.  But that's already the same now=
, so if it's an issue it's not a new one with this RFC.

It is a new issue. Today, interruptible functions must include a
`yield` statement, so they are explicitly interruptible.

> Your average unaware developer can continue to happily use any libraries =
they want without encountering any async issues.  The calls from outside th=
e library will still be blocking, as PHP will still be single threaded.
>
> Thanks,
> Peter
>
>

I feel like we're going round in circles a bit, and I don't want to
drown everyone in emails, especially as we're out of the discussion
period for this RFC. I will try to clarify my point and attempt to
summarise the counterpoint to reduce noise.

My opinion is that, in a world of multi-vendor applications and
dependency injection, async can't safely be an implicit feature, it
needs to be explicit. It should be noted that virtually all general
purpose programming languages seem to take this view, including, for
example, hacklang.

The counter argument is: if you want to use fibers, you have to be
sure that your entire codebase, *including all of the code you import
from other vendors*, is written with fibers in mind (or is compatible
by good fortune). But this will not be made explicit in the code. I
think this is wishful thinking, and highly impractical.

And finally, to clarify one other thing, the bugs I'm talking about
are race conditions. You don't identify race conditions by executing
code, you find race conditions by reading code. So all of the code has
to be read in order to find them all, there is no shortcut. Most
people won't actually do this however.

Cheers