The project goals and prospects

[EdmondDantes]

While the ThreadPool is being developed, I have something to say about the RFC and the project’s goals.

The project has not lost hope of becoming an official part of PHP. However, there are no plans in the near future to submit an RFC or make any changes. For now, the project will rather wait for a response/action/reaction from the PHP community.

For now, the project has the status of an “experimental version” This may change over time.

Previously, the goal of the project was to integrate asynchrony into the PHP core. This task is almost complete. Let’s say version 1.0.0 is released. What’s next?

An answer to that question already exists. The next step is to turn PHP into a language capable of working in stateful applications, which is currently far from reality.
There is now a clear understanding of what needs to be done and how to approach it, unlike at the start of the project.

One of the most interesting directions is a new memory manager, code-named M3, along with a new background garbage collector designed specifically for long-running applications.

The goal is to make PHP convenient for building long-running applications, while preserving its stability and simplicity. This is a challenging task, but not an impossible one.

All of this together can change the language in terms of its internal capabilities and how it is used. Asynchrony was only a small key to that.

This is not a joke. This is not a toy. There are clear intentions to bring this project to a production-ready state.
I know there will be many people who will say: if it’s not official, I won’t use it.
My position is: a choice can only be made when there is one.

[macropay-solutions]

Congratulations! Keep up the good work.

[xingye00186]

So you choose the second option?------ requires the new M3 memory manager (with multi-threading support),
changes to the compiler to teach it to store op_array entries directly in shared memory,
and avoiding unnecessary copying altogether.
Sounds good and respect!

[EdmondDantes]

So you choose the second option?------ requires the new M3 memory manager (with multi-threading support),

Yes, I think that after version 1.0 it makes sense to continue working on performance improvements for multithreading.
At the same time, these changes do not affect user PHP code in any way, but PHP will be able to extract more performance from threads.

[EdmondDantes]

The second point to consider: although the Spiral team tried to make PHP long-living, the experiment wasn’t very successful. Why? Because writing such code in PHP right now is very difficult. Memory leaks still exist. Sprinkling WeakRef everywhere makes the code more complex.

So a new GC could not only improve performance by collecting garbage in the background, but also eliminate the need to think about writing code in a way that avoids cyclic references.

Moreover, if PHP could easily help detect memory issues, the attitude toward it would change very quickly.

[ElonJTrump]

This project is really interesting. I've ever used "Swoole" the serious problem of "Swoole" is document is not clear and not update when they change the major version. I totally agree with you and not understand why PHP official team is not focus on asynchronous (and coroutine) feature this will change PHP forever.

[NathanFreeman]

Could you share what specific aspects of the Swoole documentation are not very user-friendly? We are currently planning to optimize the overall documentation. Your feedback is very important to us, thank you!

[ElonJTrump]

I always read document from https://wiki.swoole.com/en/#/ and this show Updated at：2024-04-12 10:42 I think this for Swoole 5 and many of API in document seem to be not available any more in Swoole 6

I think if document can be separated to correct version it would be nice.

[lucaswitch]

This is the actually right way to go when it comes to modern languages multithreading. Kotlin and Swift are a good examples to follow in that aspect, for what i know they solve that in such a beautiful way.

There is an option like Edmond said, to still have this shipped alongside PHP 8.6 as an extension.

Multithreading would be nice v2 with lets say for a future php version like 9 or 10.

[phpclub]

First of all — thank you, @EdmondDantes. Your fork of Unit with TrueAsync graceful shutdown (nxt_php_quit_handler + ZEND_ASYNC_SHUTDOWN()) is exactly what we needed. We cherry-picked your commit into FreeUnit — the community LTS fork of the archived Unit application server — with full attribution: freeunitorg/freeunit@b78e5a4.
On top of that we added a test suite (8 pytest cases) covering graceful shutdown on reconfigure, SIGQUIT, zombie prevention, in-flight request completion, and multi-worker exit: freeunitorg/freeunit@e3ac751. Tests are currently skipped pending two C-side blockers (nxt_php_app_conf_t missing async/entrypoint fields and nxt_php_extension.c not yet ported), documented in our TODO.md. Unit's long-running worker model is a natural fit for TrueAsync — we'd love to collaborate on resolving those blockers.

[EdmondDantes]

Hi,
Thank you a lot.

I’d like to highlight a couple of points:

1. There is a slightly better implementation for FrankenPHP, although it should still be considered “raw.” However, performance tests have shown that even it is enough to reach Swoole-level performance.
2. If it’s possible to redesign UNIT into a multi-reactor → multi-worker model, it could deliver excellent performance.

Also note that the current TrueAsync ABI has changed a bit, and the integration scheme has been updated as well:
https://true-async.github.io/en/architecture/frankenphp.html

There is still no good channel implementation that can efficiently wake up the EventLoop, but as I mentioned earlier, this is not critical. Performance can be further improved by learning how to distribute requests across threads efficiently.

[phpclub]

For now, this is an optional build for the future - I'm currently trying to solve a critical bug freeunitorg/freeunit#28

[KingBes]

给你点个赞👍

[ctfang]

This is a fascinating direction