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
------------------ Original ------------------
From: "Aaron Piotrowski"<aaron@trowski.com>;
Date: Wed, Mar 10, 2021 04:02 PM
To: "php internals"<internals@lists.php.net>;
Subject: Re: [PHP-DEV] [VOTE] Fibers
> On Mar 8, 2021, at 1:40 PM, Aaron Piotrowski <aaron@trowski.com> wrote:
>
> Greetings everyone!
>
> The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers <https://wiki.php.net/rfc/fibers>;
>
> Voting will run through March 22nd.
>
> Cheers,
> 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-case 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 – 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 step.
Cheers,
Aaron Piotrowski
To unsubscribe, visit: https://www.php.net/unsub.php
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
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
------------------ Original ------------------
From: "Aaron Piotrowski"<aaron@trowski.com>;
Date: Wed, Mar 10, 2021 04:02 PM
To: "php internals"<internals@lists.php.net>;Subject: Re: [PHP-DEV] [VOTE] Fibers
> On Mar 8, 2021, at 1:40 PM, Aaron Piotrowski <aaron@trowski.com>
wrote:
>
> Greetings everyone!
>
> The vote has started on the fiber RFC:
https://wiki.php.net/rfc/fibers <https://wiki.php.net/rfc/fibers>;
>
> Voting will run through March 22nd.
>
> Cheers,
> Aaron PiotrowskiHi 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-case
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 – 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 step.Cheers,
Aaron PiotrowskiTo unsubscribe, visit: https://www.php.net/unsub.php
I am afraid that fiber can only be used in the amphp framework and is of
no value to other php projects.
Hi,
I'd like to see you elaborate on this point. Are you able to provide
anything to back up this claim?
I don't see anything that is specific to amphp, not anything to limit it to
their use. Fibers also exist outside of PHP, while amphp doesn't.
Thanks,
Peter
Hi,
I am come from Chinese, we may have some cultural differences, and there may be some difficulties in communication. I try to express my opinion.
To be precise, the fiber can only be used for amphp and reactphp or other event-driven asynchronous IO frameworks developed using php. The RFC does not mention how an extension uses fiber.
Fiber is not like threads or processes of operating system. It is not parallel, nor is it concurrent. This requires an event-driven scheduler to have practical value. Currently php does not have event-driven support. So normal web developers don’t know how to use fiber. It is for developers of asynchronous io programming.
I just suggest first to provide a PECL extension like ext-event/ext-libevent, no need to be integrated into php now. Swoole is also provided to users as a PECL extension.
------------------ 原始邮件 ------------------
发件人: "Peter Stalman";
发送时间: 2021年3月11日(星期四) 下午2:37
收件人: "韩天峰";
抄送: "Aaron Piotrowski"; "php internals";
主题: Re: [PHP-DEV] [VOTE] Fibers
On Wed., Mar. 10, 2021, 02:16 韩天峰, <rango@swoole.com> wrote:
> I am afraid that fiber can only be used in the amphp framework and is of
> no value to other php projects.
>
Hi,
I'd like to see you elaborate on this point. Are you able to provide
anything to back up this claim?
I don't see anything that is specific to amphp, not anything to limit it to
their use. Fibers also exist outside of PHP, while amphp doesn't.
Thanks,
Peter
Hi,
I am come from Chinese, we may have some cultural differences, and there may be some difficulties in communication. I try to express my opinion.
To be precise, the fiber can only be used for amphp and reactphp or other event-driven asynchronous IO frameworks developed using php. The RFC does not mention how an extension uses fiber.
Fiber is not like threads or processes of operating system. It is not parallel, nor is it concurrent. This requires an event-driven scheduler to have practical value. Currently php does not have event-driven support. So normal web developers don’t know how to use fiber. It is for developers of asynchronous io programming.
I just suggest first to provide a PECL extension like ext-event/ext-libevent, no need to be integrated into php now. Swoole is also provided to users as a PECL extension.
Hello,
I agree that this feature is targeted at libraries wishing to provide better async I/O. What I disagree with is that this means it should not be a part of PHP.
Whether many developers realize it or not, several commonly used libraries already contain some async I/O features, often implemented with promises, which have some API trade-offs to attempt to integrate async into typical synchronous code. Guzzle, Symfony, and Psalm are three commonly used libraries that have asynchronous APIs available.
Having fibers available in core will allow these libraries to offer async code with an improved, more intuitive API as well as expand their use of async I/O beyond what it typically has been used for, HTTP requests, to include databases, redis, file access, etc.
An event scheduler is needed for async I/O to work, but several implementations already exist in user space and work very well with fibers, as I and ReactPHP team can attest. Fibers are the key to integrating these event schedulers into the greater PHP community.
Swoole provides an entire large, opinionated framework for async coding. That’s fantastic! However, it is not a flexible tool that any library can use for a variety of purposes. It is more akin to choosing a framework such as Laravel or Yii to write your PHP app.
Event-driven programming is desperately needed in the PHP community. Right now PHP contains nearly all the tools for fantastic, clear, intuitive user space async code. This is the one missing piece.
Aaron Piotrowski
The RFC does not mention how an extension uses fiber.
Hi,
I forgot to address your point that the RFC does not mention how an extension uses fibers.
I did omit this from the RFC as I focused on the user API, as that is typically what PHP RFCs focus on, but this is an important question.
There is not an internal API to create fibers at this time. However, I planned to collaborate with other internals developers to add this API (and of course with feedback from swoole developers), so this will be a feature available to PHP extensions.
Aaron Piotrowski
There is not an internal API to create fibers at this time. However, I planned to collaborate with other internals developers to add this API (and of course with feedback from swoole developers), so this will be a feature available to PHP extensions.
I know voting is currently on-going, but would it be out of order to add a section to the RFC that states what you’ve said here?
Cheers,
Ben
There is not an internal API to create fibers at this time. However, I planned to collaborate with other internals developers to add this API (and of course with feedback from swoole developers), so this will be a feature available to PHP extensions.
I know voting is currently on-going, but would it be out of order to add a section to the RFC that states what you’ve said here?
Cheers,
Ben
Hi Ben,
I think this is appropriate, as it is merely adding information to the RFC to answer a question that was raised on the list.
I added a “Future Scope” section with the following text:
The current implementation does not provide an internal API for fibers for PHP extensions. This RFC focuses on the user space fiber API. An internal fiber APIwill be added, collaborating with other internal developers and using feedback from PHP extension developers, including Swoole, so fibers can be created and controlled from PHP extensions. An extension may still optionally provide their own custom fiber implementation, but an internal API would allow the extension to use the fiber implementation provided by PHP.
Cheers,
Aaron Piotrowski
Hi,
I am come from Chinese, we may have some cultural differences, and there
may be some difficulties in communication. I try to express my opinion.
To be precise, the fiber can only be used for amphp and reactphp or other
event-driven asynchronous IO frameworks developed using php. The RFC
does not mention how an extension uses fiber.
Fiber is not like threads or processes of operating system. It is not
parallel, nor is it concurrent. This requires an event-driven scheduler to
have practical value. Currently php does not have event-driven
support. So normal web developers don’t know how to use fiber. It is
for developers of asynchronous io programming.
I just suggest first to provide a PECL extension like
ext-event/ext-libevent, no need to be integrated into php now. Swoole
is also provided to users as a PECL extension.
I want to answer this in a different way than Aaron did. Let's assume that
this is correct. No one will EVER use fibers except amphp and reactphp.
Let's also assume that it would work just fine as an extension (which Aaron
has shown already is not the case). If someone is willing to do the work to
add this to core, we aren't trading off other features in order to add it,
and it doesn't cause BC breaks or other bugs, what is the reason to not add
it?
------------------ 原始邮件 ------------------
发件人: "Peter Stalman";
发送时间: 2021年3月11日(星期四) 下午2:37
收件人: "韩天峰";
抄送: "Aaron Piotrowski"; "php internals";
主题: Re: [PHP-DEV] [VOTE] Fibers
On Wed., Mar. 10, 2021, 02:16 韩天峰, <
rango@swoole.com> wrote:> I am afraid that fiber can only be used in the amphp framework and is of
> no value to other php projects.
>Hi,
I'd like to see you elaborate on this point. Are you able to provide
anything to back up this claim?I don't see anything that is specific to amphp, not anything to limit it to
their use. Fibers also exist outside of PHP, while amphp doesn't.
Thanks,
Peter
--
Chase Peeler
chasepeeler@gmail.com
Am 11.03.2021 um 17:51 schrieb Chase Peeler chasepeeler@gmail.com:
If someone is willing to do the work to
add this to core, we aren't trading off other features in order to add it,
and it doesn't cause BC breaks or other bugs, what is the reason to not add
it?
Complexity, which might come back and bite us in the long run.
Note: I'm not talking about this specific feature, more in general. I just wanted to point out that there can be reasons to not add something even though it doesn't seem to have a drawback at the moment.
- Chris