Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113450
MIME-Version: 1.0
References: <tencent_5E47DEBA2843CDD57E4DE795@qq.com>
In-Reply-To: <tencent_5E47DEBA2843CDD57E4DE795@qq.com>
Date: Wed, 10 Mar 2021 20:24:42 +0100
Message-ID: <CAPY1sU8YoToP_BaoeFxvwBePk-uTxqYJyKdidkyi380jCzQq7A@mail.gmail.com>
To: =?UTF-8?B?6Z+p5aSp5bOw?= <rango@swoole.com>
Cc: Aaron Piotrowski <aaron@trowski.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000026e33605bd339f4c"
Subject: Re: [PHP-DEV] [VOTE] Fibers
From: ceesjank@gmail.com (Cees-Jan Kiewiet)

--00000000000026e33605bd339f4c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Tianfeng.Han,

> I am afraid that fiber can only be used in the amphp framework and is of
no value to other php projects.

My name is Cees-Jan and I'm one of the core maintainers of ReactPHP, and I
strongly disagree with this statement. While it might not be of value to
Swoole, it will provide a lot of value to the ReactPHP ecosystem. Even when
we won't implement it throughout the project, but only at the edge our
consumers will benefit from greatly the edge support. Building a Guzzle
adapter is suddenly feasible again because we can pause at specific points
and make them compatible. We can do full native PSR-15 suppose in
react/http for the exact same reason when fibers land in core. In the past
I used monkey patching and Generators for this, and also did a version with
ext-parallel. But fibers? Fibers will make this native without the need for
hacks or make awkward use of extensions.

> In my opinion, Fiber is just an enhancement of Generator.

In a sense it is, and I very much welcome that. And I don't see that as a
bad thing, especially since Generators where never designed with this use
in mind. So having a dedicated API for it is a huge plus for me.

Cheers,

Cees-Jan



On Wed, Mar 10, 2021 at 11:16 AM =E9=9F=A9=E5=A4=A9=E5=B3=B0 <rango@swoole.=
com> wrote:

> Hi everyone:
>
>
> My name is Tianfeng.Han, I am founder of Swoole project. We have done a
> lot of exploration in cli server side programming of php.
>
>
> I think, ext-fiber is more suitable as a PECL project. Coroutine and
> asynchronous IO is a new concurrency model, This is very different from
> blocking IO.
>
>
> I am afraid that fiber can only be used in the amphp framework and is of
> no value to other php projects.
>
>
> If the PHP language wants to support CSP programming like Golang,
> asynchronous IO and coroutine system can be designed in the next major
> version (PHP9), this requires a lot of work.
>
>
> from: Tianfeng.Han
> date: 2021/03/10
> &nbsp;
> ------------------ Original ------------------
> From: &nbsp;"Aaron Piotrowski"<aaron@trowski.com&gt;;
> Date: &nbsp;Wed, Mar 10, 2021 04:02 PM
> To: &nbsp;"php internals"<internals@lists.php.net&gt;;
>
> Subject: &nbsp;Re: [PHP-DEV] [VOTE] Fibers
>
> &nbsp;
>
>
> &gt; On Mar 8, 2021, at 1:40 PM, Aaron Piotrowski <aaron@trowski.com&gt;
> wrote:
> &gt;
> &gt; Greetings everyone!
> &gt;
> &gt; The vote has started on the fiber RFC:
> https://wiki.php.net/rfc/fibers <https://wiki.php.net/rfc/fibers&gt;
> &gt;
> &gt; Voting will run through March 22nd.
> &gt;
> &gt; Cheers,
> &gt; Aaron Piotrowski
>
> Hi all!
>
> A concern was raised off list that due to the complexity of the way this
> feature interacts with the engine, it may be best to mark the feature as
> experimental. This would allow some changes to be made to certain edge-ca=
se
> behaviors and, while I don't think it would be necessary, the public API.
>
> We (Niklas and I) agree with this and propose that if this feature is
> accepted, it is marked as experimental through the 8.x release cycle or
> until we're comfortable removing that label, whichever comes first.
>
> Experimental in this context would mean fibers would be compiled and
> available in all releases, but the documentation would denote that
> behavioral and API changes may be made in future minor releases =E2=80=93=
 use at
> your own risk.
>
> As this feature is targeted at library authors and not average PHP users,
> we believe there would be little effect to the community to take this ste=
p.
>
> Cheers,
> Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

--00000000000026e33605bd339f4c--