Hello, *Jakub.* (It seems that simply clicking "Reply" does not work for the conference)
*> *I understand that's not ready for review yet but quickly You could say that the code is in a state of "architectural stability," so it can be reviewed and criticized. (Unfortunately, only the Windows build is currently working.) In the near future, I plan to start documenting the C-API, where I will describe the implementation details in depth, but feel free to ask any questions about this component. Link: https://github.com/EdmondDantes/php-src/tree/async/async > Is there some particular reason why this is not an extension? There are two reasons: one objective and one relatively subjective. *The objective reason* is that there are critical changes that simply cannot be done in an extension. This includes modifying the logic of functions like php_select/php_poll2. The relatively subjective reason is that it was extremely difficult for me to design the architecture within the constraints of an extension because, at the start of the project, I had no clear idea of how to implement it at all... :) Theoretically, the project could be split into two separate components: core modifications and an external EXT component. Now that I have a working codebase, it would be much easier to do. And yes, you've raised a very important point. In CGI applications, this component is likely to be of little use (although in some cases, it might still be beneficial even for CGI). So keeping the entire codebase in the PHP core is not a good approach. I’m sure many people will point that out :) And I agree. But for now, the component is built using configuration options in buildconf, which is sufficient as a starting point. If your question is whether core modifications could be avoided, the answer is no. The whole purpose of this project is to make PHP more suitable for LongRunning Apps. > and then libuv optional part - similar to pdo for example. That's exactly how it has already been implemented! *LibUV* is not tightly coupled to the code. Moreover, it can be replaced on the fly with any other implementation—for example, Swoole can serve as the backend for the reactor, or RUST TOKIO, or perhaps someone might want to create something else. In essence, the Reactor is just an API and can be defined via an extension. LibUV is included as an embedded piece of code that can be compiled directly with the project if a specific flag is set, but of course, it can also be provided as an extension. (The reason why LibUV is provided as the "default solution" is that it is written in C and is cross-platform. This is important for PHP. ) I plan to do the same with the Scheduler component in the future. Thanks for questions! пт, 14 февр. 2025 г. в 15:05, Jakub Zelenka <bu...@php.net>:
