Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113590
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>
In-Reply-To: <CAPrKfG79Y4=SVFDFipXBpaEh+o_-kgQ38-=evR4GvgKZaOSmRw@mail.gmail.com>
Date: Wed, 17 Mar 2021 14:40:52 +0000
Message-ID: <CAKiSzdCPPM-s7yA75dJqS7N4j-VQHCfuXc5K6Zrh+sm_bdSUHQ@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)

On Wed, Mar 17, 2021 at 9:06 AM Peter Stalman <sarkedev@gmail.com> wrote:
>
> On Tue., Mar. 16, 2021, 23:49 Josh Di Fabio, <joshdifabio@gmail.com> wrot=
e:
>>
>> 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 resol=
ve them itself before continuing, no?  If `capturePayment()` starts a fiber=
 then 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=
 are 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.
>
>
> No, they don't need to yield.  You can do `$guzzleClient->requestAsync()`=
 today, so how is it different?
>
> Thanks,
> Peter
>
>

Hi Peter,

I am referring to functions which can be interrupted or suspended.

Guzzle's requestAsync() returns a promise, it does not
interrupt/suspend the callsite. For example:

    // this function is not interrupted/suspended -- it will return
synchronously
    function doSomething() {
        $this->guzzle->requestAsync(...)->then(... handle response here ...=
);
        echo "This will be printed before a response is received";
    }

The following is similar to how one would implement an coroutine in
PHP today when using a library which implements a coroutine mechanism,
such as amphp. Note the yield statement which interrupts/suspends the
function:

    // this function will be suspended while the request is in flight
-- it will return after a response is received
    function doSomething()
        $response =3D yield $this->guzzle->requestAsync(...);
        // do something with response here
        echo "This will be printed AFTER the response comes back";
    }

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).

Cheers