Two PHP Development Strategies

[EdmondDantes]

After running tests on WordPress and Laravel, as well as reviewing the Laravel Octane issues, I can present two strategies for analyzing the future development of the language in terms of asynchrony and multithreading.

Before accepting the RFC or making other decisions, it is important to answer these questions, because they define long-term prospects that cannot be easily changed later.

Before I describe the two strategies, I want to briefly outline the results of experiments with the single-threaded coroutine model.
The experiments showed that products like WordPress and Laravel require refactoring in order to work as stateful applications.
The part of the code that contains global state and interacts with I/O needs to be changed. However, there is much less of this code compared to the rest, which makes such refactoring feasible.

Strategy 1: Gradual Changes

The first strategy assumes gradual evolution of the language:

1. Adding single-threaded coroutines
2. Adding coroutines in other threads
3. Adding coroutines across multiple threads with their scheduling between threads (Go model)

Steps 2 and 3 will require significant future changes to the language, not only at the engine and library levels, but also at the syntax level. This will require the development of tools for describing thread-safe objects and proper handling of object transfer between coroutines.

Strategy 2: Go-like Coroutines + Smart memory isolation

The second development strategy proposes that PHP will immediately receive a full set of changes for creating multithreaded coroutines with a complex scheduler.

Disadvantages

Disadvantages of the Second Strategy:

1. Requires a long-term roadmap.
2. Requires a significant number of man-hours.
3. Requires major changes in PHP and its libraries.
4. Essentially represents a new programming language.

Disadvantages of the First Strategy:

1. Higher developer responsibility and a higher risk of writing incorrect code.
2. The existence of two types of coroutines in the future.

P.S.
As for my personal opinion at this point, it is simple. As an engineer, I like the second approach. It is ideal, clean, and elegant. As a manager, I see no resources for its implementation and consider it almost impossible.

[xingye00186]

Some server applications are like a corporation with multiple factories, where each factory is divided into task steps for collaboration. The actual production demand of the corporation determines whether to activate one production line or multiple lines, but each line can only carry a certain number of task units. Exceeding this limit will also cause task units to queue up.

Coroutines indeed can significantly improve operational efficiency by avoiding wasteful waiting, but it is also essential to reasonably plan the number of task units (coroutine count) on the production line (process or thread) to avoid congestion caused by task pile-ups.

Therefore, for large applications (corporations), the architecture must not only consider introducing coroutines or multithreading but also the overall task division and collaboration.

But for current PHP, even without considering the overall architecture or multithreading, simply introducing coroutine features can bring efficiency and throughput improvements to I/O-intensive applications.

[deleugpn]

I don't think option 2 would ever be possible with the RFC process and the PHP language as it is. That could probably only work as a fork. And this is assuming we could magically produce all the man-hours necessary to make it even work.