Hello > Hierarchies of scopes make for a lot of complexity. I doubt whether this is > useful in most cases.
https://dl.acm.org/doi/10.1145/3547276.3548519 Here’s a short article about the basics of asynchrony and structured concurrency. Please look at icppworkshops22-13-fig4.jpg The logic of a Scope largely mirrors that of variable scopes. There’s a direct logical parallel here: a scope defines a variable’s lifetime. In asynchronous programming, it’s often necessary to have multiple scopes that depend on each other in a parent → child relationship. That’s what structured concurrency is. > There is a lot of complexity and I still also think this RFC is trying to do > way too much. Why is that even a problem? There are many complex things in programming, and languages support complex features for example, classes, inheritance, and traits. PHP even plans to introduce generics, which are very sophisticated abstractions. If we follow the logic of “nothing complex,” then PHP should remove all advanced abstractions and become a language only for "simple websites". But I think many developers would disagree because they want to make money. And if a language doesn’t support complex abstractions, it limits their career. Of course, I could have made this RFC similar to Go: with only coroutines and channels. But then there would be no way to limit the lifetime of coroutines from code that doesn’t know about them. I could also have made it more like Kotlin: but then it would have been even more complex. Instead, this RFC was designed specifically to fit PHP. The current approach `Scope` + `Cancellation policy` makes asynchronous code safer and simpler. It allows monitoring all coroutines from a single place in the code (One point of responsibility). Just look at the code examples with CancellationToken to see the benefits these tools provide. Without Scope, the programmer would have to manually track different coroutines and pass cancellation tokens into each of them to limit their lifetime. I’ve had that experience and I know the true cost of such complexity. > and the goal of adding concurrency into it should make the live of web > developers easier Asynchronous programming doesn’t make a developer’s life easier, quite the opposite. Asynchrony is one of the most complex areas that programmers have successfully avoided for many years. If a developer approaches asynchrony thinking it will make their life easier, it means they don’t understand it at all. Concurrency is used to squeeze the maximum performance out of the CPU by reducing the number of kernel API calls and keeping the processor busy with useful work. That’s the main reason. Asynchrony requires additional effort from developers because modern backend solutions operate under much heavier loads and use far more complex interaction algorithms than they did ten years ago. The real truth is that it didn’t matter much before, but now it does. > This seems to be designed fo running PHP as a long time running script/event > loop. We have web servers and FrankenPHP for that. FrankenPHP doesn’t make PHP asynchronous. > The RFC also doesn't describe how scheduling works. You call it "out of > scope", but as this is needed for this whole concept to work, it very > much ought to be in scope. > **but as this is needed for this whole concept to work** Could you explain with an example what exactly wouldn’t work? I’ll try to help you work through this question. When you write a program, how do you account for the operating system’s scheduler algorithm? In the current implementation, the Scheduler is a queue based on a circular buffer. Swoole, for example, implements a scheduler with preemptive multitasking. In principle, this could be done at any time and it would not affect this RFC in any way. > "The format of this array depends on the implementation of the Scheduler and > the Reactor." I didn’t define the format of debugging information in the RFC because it may change over time. Besides that, the Scheduler and Reactor components can be replaced with others the ABI allows this. Different implementations might also want to include different metadata, which is perfectly normal. > Isn't that what you would expect people to use concurrency for? These questions are answered in other messages in this thread. > I don't understand why the "NGINX Unit integration example" is part of this > RFC. Sorry but I don’t understand the point of this question. What’s wrong with the example? > In my opinion, it was not wise to spend so much time on the code (beyond > prototyping). The role of the RFC process is to hammer out a good feature for > PHP, with the code being (mostly) an implementation detail. Years of design experience show that any complex system must be developed together with the code, because purely abstract ideas are always flawed. This RFC was created using an iterative approach, where design phases alternate with implementation phases. For example, the rules defining where coroutines can be launched were determined by the implementation, not by the RFC. It was also important to assess whether the project was justified whether it should be implemented in the PHP core at all. Today, I know the answers to those questions. > The "Goals" describe what you would like this feature to be, but not *why*. > The > RFC does not describe why this feature is important for PHP for specific use > cases at all. The RFC contains many explanations of what each abstraction is used for. Of course, I might have made a mistake or forgotten to describe something. So if you have any questions, feel free to ask. Best regards, Ed
