Re: PHP True Async

On Fri, Feb 14, 2025, at 15:16, Edmond Dantes wrote: > 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 <bukka@php.net>: > >>> Hello, I'm actually curious why you chose libuv? This may no longer be true today, but I remember distinctly not choosing libuv on a previous project due to some compatibility concerns. It was a php project + custom extensions, and the issue was directly related to other official/pecl extensions. We didn't have this issue with libev, fwiw. It was a long time ago though, so maybe the issues no longer exist, and I don't remember the details. — Rob