> On Mar 12, 2021, at 3:00 AM, twosee <tw...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
