Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113062
Message-ID: <tencent_07DC60EE8CF79BB672A7ED186E65A9068205@qq.com>
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
Date: Wed, 3 Feb 2021 23:39:35 +0800
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
To: Aaron Piotrowski <aaron@trowski.com>
Subject: Re: [PHP-DEV] [RFC] Fibers
From: twose@qq.com (twosee)

> 2020=E5=B9=B412=E6=9C=8818=E6=97=A5 =E4=B8=8A=E5=8D=8812:30=EF=BC=8CAaro=
n Piotrowski <aaron@trowski.com> =E5=86=99=E9=81=93=EF=BC=9A
>=20
> Hello everyone!
>=20
> I would like to introduce an RFC for adding full-stack fibers to PHP: =
https://wiki.php.net/rfc/fibers
>=20
> Fibers are primarily used to implement green-threads or coroutines for =
asynchronous I/O. Fibers are similar to threads, except fibers exist =
within a single thread and require cooperative scheduling of the fibers =
by the process. Since fibers do not require a full CPU context switch, =
they are lightweight and more performant than multi-processing or =
threading for awaiting I/O.
>=20
> An implementation as an extension is at =
https://github.com/amphp/ext-fiber
>=20
> Fibers are a complex feature. The RFC contains many examples and links =
to code using fibers to help explain and demonstrate what is possible, =
however I=E2=80=99m certain many more questions and concerns will arise. =
Looking forward to feedback and discussion.
>=20
> Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20
>=20


Hi there,

So glad to see that the RFC of Fiber is back on the agenda.

Let me introduce myself first. I'm a very active contributor to Swoole =
and also a core member of the Swoole developing group.

Though Swoole has not been mentioned in the RFC, Swoole has already =
worked for async/coroutine feature for many years and always doing best =
in order to be merged into php-src. It's extremely difficult to merge =
Swoole into php-src fully because Swoole is systematic and complex. Even =
the coroutine is a core but also a tiny part of Swoole.=20

In recent years, Swoole has been committed to improving stability and =
overcoming technical problems. It can be said that the current Swoole is =
very close to the ideal status. What's more, Swoole has been applied =
widely by advanced enterprises in China. It has been verified by a large =
amount of real-world applying. We may have more practical experience in =
many details of the implementation of coroutine technology

For the core of Fiber, the context switching of C stack and PHP VM =
stack, there is no more obvious problem. But there is somewhere worth =
improving, indeed. Furthermore, we may do more context switching, since =
Swoole may yield from PHP internal function, which would make the "@" =
not work.

As we could see, the main controversy is what about the FiberScehduler. =
I think it is designed for the amphp, however, it makes code hard to be =
comprehended, and it was unnecessary if we just want a minimum coroutine =
implementation.

Just having creation and switching is enough for a minimum coroutine =
implementation. So did the last Fiber proposal. The implementation of =
the scheduler is still debatable.

Otherwise, compared with the previous Fiber proposal, the most valuable =
change in the new Fiber proposal is the introduction of C stack =
coroutine technology.=20

In my opinion, the goal of the new Fiber proposal is not that ambitious. =
It just eliminates the stack pollution caused by Promise. This makes the =
style of PHP coroutine neither like the Nodejs which represents the pure =
stackless coroutine, nor the Lua and Golang which represent pure stack =
coroutine.

Once PHP has a stack coroutine like Fiber, we can do more than what we =
can do now. Since we can interrupt from PHP internal functions, then we =
can replace all the implementation of PHP blocking functions, such as =
sleep(), and we can also replace php_stream so that we can change the =
implementation of PDO, mysqli, and phpredis into a coroutine way, and we =
can also make curl become a coroutine version through libcurl's support =
for multiplexing.

In fact, many years ago, amphp-liked solutions were very popular in the =
Chinese PHP community. But they were replaced by Swoole, eventually.=20

Performance is one of the reasons. Because, indeed, parsing protocol by =
PHP is disadvantaged compared to parsing by C. Though the amphp-liked =
solutions dose expand the PHP's capabilities, the performance is not =
that satisfactory. However, Swoole performs like other static languages.=20=


On another hand, the replacement cost. What has been proved is that most =
PHP programmers want to continue to use common clients such as PDO, =
mysqli, phpredis, and curl, and the great PHP package and library =
ecosystem based on these clients is hard to replace. The cost of moving =
a modern PHP application to Swoole is so low which was unimaginable =
before. Many success cases there in the community.

So what I want to explain is that once the PHP core is ready to accept =
the Fiber proposal, everyone will start to think, what is the next? =
Therefore, what Fiber's goal is what the Fiber extension is designed for =
are particularly important. What I really care about is - does it just =
simply eliminates the pollution of the stack caused by Promise, or it =
plans to improve the performance of PHP applications by a hundredfold at =
a low cost as Swoole did.

Regards,
Twosee=