> On Mar 12, 2021, at 3:00 AM, twosee <twose@qq.com> wrote:
>
> 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.
>
Hi Twosee,
I wanted to address the point above from your email. I do not think auto-magically altering the
behavior of existing functions to use async I/O is a good idea. Existing code that relies on a
constant state during an I/O operation that previously was blocking may no longer work as expected.
Changing behavior is a major BC break. It would be better to introduce new async versions of
functions, e.g., asio_fwrite(), instead of altering the existing fwrite() function. This way
libraries which have interfaces requiring blocking I/O, such as libraries implementing PSR-7/15, can
create versions that are designed with async I/O in mind, while keeping existing implementations
working as expected.
Changing the behavior of existing functions reminds me of the mbstring.func_overload
feature that is now deprecated because of the compatibility problems it caused.
I took a look at Swow this morning. Again, I would compare Swow to Swoole – it is another large,
opinionated framework for asynchronous PHP apps. Swow is not a lightweight, standalone feature that
can be merged into PHP at one time. The Fiber API is small in scope and does not alter existing
behaviors.
Looking at the fiber implementation in Swow, I see it uses the same boost library and the same
asymmetric coroutine model as ext-fiber. It seems Swow could use an internal API provided by PHP for
fibers, allowing it to drop the boost dependency.
This leads me to believe my proposal would be mutually beneficial to both your extension and the
wider PHP community that could use fibers outside of your framework or Swoole.
Cheers,
Aaron Piotrowski