Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113493
Message-ID: <tencent_C6C6E4DB7377BC37B42C3B38C7CC2B093508@qq.com>
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
In-Reply-To: <CA+kxMuSu=LS2BGjE0YYpOedVGq3dFXBSaqMdNtVkg0G2P73ywQ@mail.gmail.com>
Date: Fri, 12 Mar 2021 17:00:33 +0800
Cc: =?utf-8?B?6Z+p5aSp5bOw?= <rango@swoole.com>,
 Aaron Piotrowski <aaron@trowski.com>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <D376DEFE-26A4-4F11-8548-D9454087E9FD@trowski.com>
 <8812EE70-4720-4639-926E-1EA206624BC1@trowski.com>
 <tencent_7FEAF879A5A1468B5C6FEE807780767DE705@qq.com>
 <CA+kxMuSu=LS2BGjE0YYpOedVGq3dFXBSaqMdNtVkg0G2P73ywQ@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Subject: Re: [PHP-DEV] [VOTE] Fibers
From: twose@qq.com (twosee)

> 2021=E5=B9=B43=E6=9C=8812=E6=97=A5 =E4=B8=8A=E5=8D=885:50=EF=BC=8CDan =
Ackroyd <Danack@basereality.com> =E5=86=99=E9=81=93=EF=BC=9A
>=20
> Hi Twosee, Tianfeng.Han
>=20
> I was drafting a longer reply to you both, but I realised I might be
> missing some information.
>=20
> Please could you disclose the commercial interests of the Swoole
> maintainers, and the ties to the for profit companies that provide
> services implementing Swoole?
>=20
> Having people vote on RFCs who have ties to companies that provide
> services via commercial entities isn't unprecedented. For example
> zend.com has had employees who are involved in voting on RFCs, but to
> a large extent that was done openly, with all of them using zend.com
> email addresses.
>=20
> twosee wrote:
>> Of course, the Swoole community still expects to merge it into =
php-src at an appropriate time.
>=20
> What's your idea of an appropriate time and how do you plan to start
> this conversation?
>=20
> If something hasn't been merged back after 8 years, it sounds
> reasonably unlikely that it's ever going to be merged back.
>=20
> cheers
> Dan
> Ack
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20
>=20

Hi all,

The following are some of my personal views, any comment is welcome:

> What's your idea of an appropriate time and how do you plan to start
> this conversation?

Maybe, I misunderstood the rules of the PHP RFC voting. In my opinion, =
the PHP RFC drafters need to have considerable experience in PHP kernel =
development (I mean that I don=E2=80=99t think I have met such =
requirements yet). And the RFC content needs to be fully verified by =
unit tests and actual projects, and the API or code implementation =
should be very stable. Once determined, no major changes will be made in =
principle.

But now, there is another way shown in front of me. We can draft an RFC =
first, then complete it based on community feedback, mark it as =
experimental, and continue to iterate in the PHP core. What I have to =
admit here is that drafting Swow's RFC will be more difficult than =
Fiber, because the content of the former is many times than that of the =
latter. However, to my surprise, it seems that there are not as many =
people who care about the details of the internal implementation as I =
thought. Most people care more about the content in the user space, and =
things under the user space are very easy to modify.

In addition, due to language and network barriers, people active in the =
Swoole community rarely participate in discussions in the PHP core =
community. In fact, I started subscribing to the PHP internal mailing =
list in July 2020 and occasionally show my opinion there. I often worry =
that incorrect translations will cause my intentions to be =
misinterpreted, and other members of the Swoole community never =
participated in discussions. We hardly use non-local social media. I =
just registered an account on Reddit, a great community exchange website =
yesterday, and I haven't had time to read all the discussions on that.

For all of the above reasons, it is extremely difficult for me to draft =
the RFC, and I have always hoped that I can make more contributions to =
other aspects of the PHP kernel, and then try to propose a huge =
coroutine draft as a goal of PHP9. And I have not taken the first step =
so far, I am very sorry about that.

Anyway, I will share content about Swow soon and try to draft a =
proposal.

> If something hasn't been merged back after 8 years, it sounds
> reasonably unlikely that it's ever going to be merged back.

Swoole does have a long history, what I have to point out is that the =
early Swoole did not really participate in the international open-source =
community. And Swoole switched from the pure asynchronous mode to the =
coroutine mode in 2018. At that time, we found that the PHP kernel has a =
good wrapping for various IO operations. We only need to implement the =
coroutine version of php_stream_wrapper to turn all relevant synchronous =
clients into coroutine clients or make synchronization blocking file =
operations into coroutine way. In this case, we can use a very small =
amount of work to achieve the reuse of most of the original libraries of =
the PHP native ecosystem. But Swoole gradually becomes a C++ project =
with some technical plan, so that it makes Swoole hard to be merged into =
php-src.

I started programming in 2017 and contributed to the Swoole project in =
2018. In 2019, I learned and mastered almost all the technical content =
of Swoole. In 2020, I obtained a php.net account. At the same time, I =
also created a new systematic pure C coroutine project called Swow (for =
sure, it can be called any other name, but the name Swow is only respect =
for Swoole because Swow leans in the implementation principle of Swoole =
and its technical experience) , and I plan to propose a systematic draft =
of coroutine this year. I have paid my best to accelerate this process. =
For the PHP community, everyone really needs a real =
asynchronous/coroutine solution. Therefore, I totally understand the =
criticism of the slow progress. But, sorry from the bottom of my heart. =
I can't do it faster.

> Are you saying that by adding this Fiber code to core it will prevent
> Swoole from functioning? If so, that is concerning.  Or are you
> simply saying that Swoole doesn't like this implementation and will =
not use
> it with their own code?

First of all, please let me pay tribute to your work. I fully understand =
that the implementation of Fiber could be indeed compatible with =
Swoole/Swow because theoretically nothing is incompatible. However, =
undoubtedly, for some reasons I mentioned or not mentioned, this =
requires a considerable amount of work. Of course, I am not completely =
denying the feature of Fiber, I just cannot agree with the merger of =
ext-fiber now. We always regard merging the coroutine system into =
php-src as a systematic plan. Even if the implementation of ext-fiber is =
merged, I am still willing to overcome difficulties to make more changes =
to promote the merger of Swow into php-src, it's my pleasure.

> One thing to consider when comparing the Fiber implementation is that =
the
> vast majority of PHP applications are still run behind a web server in
> short-lived requests.  Unlike Swoole, Swow, and Parallel, it isn't =
limited
> to ZTS or CLI.  It might not be the ideal solution, but IMO it is a =
step in
> the right direction for PHP to allow for better async support.

There is a misunderstanding here. Swow has made improvements in this =
area. It supports NTS, ZTS, supports running under all SAPIs (including =
FPM), and also supports running under all operating systems.

Now, Swow's working principle is a bit like Opcache. Opcache will =
optimize and replace the CPU instructions, which executed by the code, =
and Swow will replace the blocking system calls with the corresponding =
coroutine operation. They hardly change the behavior of the code. =
Opcache makes The program runs faster, and Swow can make the program's =
IO concurrency better.

Therefore, all PHP programs will benefit from it. We can directly use =
the synchronous-blocking guzzle. Any network IO will only block one =
coroutine instead of the entire process. You just need to open more =
coroutines to get better concurrency performance. For amphp and =
reactphp, after that, `stream_select()` and `curl_multi_select()` will =
become the coroutine version, and even they will no longer block the =
entire program.

Generally, the solution provided by Swow is completely a superset of =
Fiber.

By the way, Tianfeng=E2=80=99s translation may have caused some =
misunderstandings. I think what he wants to express is that Fiber is not =
a feature that can directly benefit all PHP projects. Of course, I know =
that the RFC has mentioned that Fiber is mainly provided for the author =
of the framework and library uses. Sorry for this that caused =
misunderstanding.

Regards,
Twosee=