Hi, On Fri, Feb 14, 2025 at 3:21 PM Edmond Dantes <edmond...@gmail.com> 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. > Yeah we are actually planning better API for this supporting epoll and kqueu which is long over due. There are other use cases for this so hopefully it will get prioritised soon. > 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. > You could still achieve this in extensions. But if you really wanted to have some main part, then it should rather go to main/ like streams and other similar stuff. > 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. ) > Yes and that's why it would better to the ext directory. > I plan to do the same with the Scheduler component in the future. > > Thanks for questions! > I have got some additional feedback from our discussion that we just had with the PHP foundation devs. It was that it looks like an async/await implementation with fiber switching which is something that was explicitly decided not to be done in fibers RFC - https://wiki.php.net/rfc/fibers (read FAQ). The reasoning was that this should be done in user space. So you should properly describe in the RFC what this offers compare to user space variants (revolt/react/amp). There were also some concerns that it would makes things harder to debug in internal implementation so this should be also addressed in the RFC. It should be noted that Fibers RFC did not preclude introduction of such extensions to the core but you will likely need describe it in the RFC and show that there are good reasons to include. Hope it helps! Kind regards, Jakub
