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 <bu...@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
