Stage 1: Memory model and its impact on refactoring #8
Replies: 5 comments 24 replies
-
|
Hi all. Senior software artisan here with 15 years of PHP experience, 8 years of async PHP experience (amphp v2, then v3), 5 years of go experience, 3 years of Rust experience, and much more. My recommendation for async PHP is:
This model matches the status quo in golang and amphp v3: from my 8 years of experience in writing async both business logic and abstraction logic in multiple languages, this is the best concurrency model. Some evidence: I maintain MadelineProto, the biggest PHP MTProto client. MTProto is an async binary protocol over TCP (no HTTP involved), requires heavy caching in order for clients to function correctly, and a lot race-heavy abstractions. MadelineProto is a framework which contains a fully async MTProto client. I migrated MadelineProto to async PHP with amphp v2 (colored, stackless async) in 2018, and then to amphp v3 (colorless, stackful async) in 2022.
Outside in PHP: in 2020, I started writing heavily async business logic in Go, and was very positively surprised by the superior developer experience, especially when using async: I was also very pleased to learn that Go encourages (not forces) the use of the actor model through channels. In my professional Go experience, I wrote heavily concurrent and massively parallel, high-load services, and golang's stackful, colorless approach. I also used Rust to write async business logic, and suffered from the same issues I suffered with amphp v2: large amounts of boilerplate await keywords, heavily impacting UX. To this day, I consider Go's approach superior to that of any other language, confirmed by extensive development experience. |
Beta Was this translation helpful? Give feedback.
-
|
From the PHP Engine side, we can provide developers with additional tools to help detect errors. For example:
The In addition, code safety can be reinforced through a special directive at the package / Composer level. There was also an idea to use a flag in php.ini. This gives us several mechanisms at once to avoid unintended side effects. |
Beta Was this translation helpful? Give feedback.
-
|
Treating WordPress and other code using globals heavily as not target for this proposal is likely path to rejection. It was already expressed by couple of voters that such approach is a no-go (it was in FPM context but I would guess it will be the same here) and if you consider that there are probably some "no" votes just based on the complexity and opinion that this is not needed at all, then I think there is not much chance this could pass. So I think the most likely model to pass is shared nothing. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it would resolve much because you can often have framework calls using the globals. This is quite usual in WP for example but likely similar in legacy frameworks as well. In other words I'm not sure the opt in mechanism is enough to get us over those objections. |
Beta Was this translation helpful? Give feedback.
-
|
Well if others think that we should at least try this approach, I wouldn't mind to try it in the next version of the RFC. Basically it would be something like giving the tools to separate globals / static members and clearly describe the potential pitfalls of sharing globals (which I think was even a bigger problem in the last version of the RFC). So something along the lines to improve the text and see what the voting result is if all other problems are ironed out (like the errors which resulted in quite a few other no's). If that fails, we could look to other models. |
Beta Was this translation helpful? Give feedback.
-
|
I think we will vote on the memory model separately. What if there are strong opponents to the idea of |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that's the question. I thnk it might make sense to start 1 that we are sure is feasable and try to tune the RFC so it properly explains everything and see if it can pass in that form. If it doesn't pass, then it would make more sense to investigate more the other approaches. |
Beta Was this translation helpful? Give feedback.
-
Proposing model 1 only because the code is already written is tempting, but not very responsible. Then we will have an argument to abandon them. |
Beta Was this translation helpful? Give feedback.
-
|
INI approach is also path to rejection - that will give quite a few "no" votes straight away. |
Beta Was this translation helpful? Give feedback.
-
|
This is something that could be a separate vote in the same RFC. @bukka I don't think there's been a vote on no longer creating new ini settings? It seems to be more of a best practice? |
Beta Was this translation helpful? Give feedback.
-
Yeah I suggested declare as I think that would be more likely to pass IMO.
It's not prohibited but there will be likely people voting against it just because it tries to use INI. This is just based on my experiance but I might be wrong ofc. |
Beta Was this translation helpful? Give feedback.
-
|
It might be nice to in general introduce the concept of experimental language features (not covered by a BC promise, unstable, etc) that can be enabled via declare |
Beta Was this translation helpful? Give feedback.
-
|
That would require special policy RFC as we don't have concept of experimental feature in our BC gaurantees. It could be possibly grouped with the actual implementation approach (e.g. using declare). |
Beta Was this translation helpful? Give feedback.
-
I think we will hardly be able to avoid a policy if we seriously want to introduce a new feature into the language in a way that is 100% safe. But that’s part of a separate discussion. |
Beta Was this translation helpful? Give feedback.
-
|
I want to share a few thoughts regarding models 2 and 3. It seems that the shared-nothing model is an absolute winner in terms of safety. I want to point out that this does not come for free. The second memory model (as well as the first, of course) requires manual synchronization from the programmer. The third memory model requires the same as the second. The difference is that shared memory must always be declared explicitly in the language.
I have a classic PHP task that must be solved efficiently.
Each request is handled by a separate coroutine. Memory model 2 answers: Memory model 3 answers: What are the possible solutions for model 3? Readonly classes. Using actors. An actor is a class whose methods are guaranteed to be called only within a single coroutine (at the same time). Actors significantly simplify writing asynchronous code, are thread-safe, and can be freely passed between coroutines. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think that model 2 would be realisticly possible to execute in multiple threads - or at least without significantly stability issue including multiple crashesh especially if we take into accounts internal (extension) objects. |
Beta Was this translation helpful? Give feedback.
-
The second model assumes that the programmer will take care of memory access manually, just like in Go. |
Beta Was this translation helpful? Give feedback.
-
|
Yes but PHP cannot crash even if the programmer does not do the synchronization so it would require also synchronization internally and that part is not realistic IMHO. |
Beta Was this translation helpful? Give feedback.
-
This is not correct, the actor model does not automatically imply colored functions. The actor model simply relies exclusively on communication via message passing: each message received by an actor is handled in order, one at a time (the message handler runs in a single thread/fiber, no concurrency, even if the callers can invoke concurrently), and can ONLY:
In other words, this is an actor (pseudo-code, not strictly adherent to the rfc, but can be implemented right now using fibers): class a {
private int $a;
private Channel $chan;
private Fiber $handle;
public function __construct() {
$this->handle = spawn(function () {
foreach ($this->channel as [$reply, $type, $args]) {
switch ($type) {
case 'setA':
$this->a = $args[0];
$reply();
break;
case 'getA':
$reply($this->a);
break;
// And so on...
}
}
});
}
// Methods CANNOT mutate state, only send messages to $chan
public function setA(int $a): void {
$this->channel->send(__METHOD__, $a);
}
public function getA(): int {
return $this->channel->send(__METHOD__);
}
}No function coloring needed here.
This is correct. |
Beta Was this translation helpful? Give feedback.
-
|
At the same time, as mentioned above by Edmond,
A simple example would be a high-loaded, read-heavy service like the following, where an RWMutex (like in go, multiple read locks allowed, only one write lock allowed) would provide much higher throughput than an actor, simply because multiple coroutines can read the same value at the same time, and the actor isn't a bottleneck: class a {
private int $a;
private RWMutex $mutex;
public function __construct() {
$this->mutex = new RWMutex;
}
// Methods can mutate state, but must acquire the mutex (higher performance than an actor)
// Gets 1 RPS in production
public function setA(int $a): void {
// Only one coroutine/thread can acquire
$lock = $this->mutex->acquireW();
$this->a = $a;
$lock->release(); // Or implicitly via __destruct
}
// Gets 1000 RPS in production
public function getA(): int {
// Any number of coroutines/threads can acquire, much higher performance
$lock = $this->mutex->acquireR();
$value = $this->a;
$lock->release();
return $value;
}
}The above is a clear example in favor of allowing a shared memory model that allows, but doesn't force usage of actors, allowing the use of higher performance alternatives based on mutexes, in some conditions. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Stage 1 — Memory model and its impact on refactoring
At this stage of the discussion, I propose focusing on one of the three main questions.
🔑 Key Questions
1. Choosing the Coroutine Model
How coroutines should behave internally:
At the moment, the stackful coroutine model has been chosen, since it allows interaction with C functions and enables mixing C and PHP function calls.
The likelihood of using a different model is low, so this question can be considered resolved.
2. Choosing the Memory Model
How state is managed in asynchronous execution:
The current RFC proposes using the least protected memory model, where coroutines freely share global and static variables.
This question is not resolved and requires further consideration.
The choice of memory model will have a significant impact on the evolution of the language for years to come.
3. Choosing the Runtime Strategy
Defining how async integrates into PHP:
This question will not be discussed at this stage, but it remains important for the consideration of question 2.
🎯 Purpose of Stage 1
The goal of the first discussion stage is to explore the memory model for async execution in PHP.
The memory model has a significant impact on how coroutines will interact with existing PHP code. This is of primary importance. In addition, the memory model determines the direction of the language’s evolution for many years, defining whether a multithreaded model becomes possible or not.
Without resolving this question, we cannot move forward.
Important elements of the discussion can be found here:
https://discourse.thephp.foundation/t/php-dev-vote-true-async-rfc-1-6/4777
Please note the message from
Rowan_Tommins_IMSoP:
https://discourse.thephp.foundation/t/php-dev-vote-true-async-rfc-1-6/4777/75
Possible Memory Models for Coroutines
There are three potential memory models for coroutine execution in PHP:
1. No Memory Separation (current behavior)
Coroutines freely share:
Characteristics:
2. Separated Globals/Statics (objects still shared)
Each coroutine receives:
But:
Status:
3. Full Shared-Nothing Model (maximum isolation)
This model extends option 2 with strict memory isolation:
Rules:
RefCount > 1.Advantages:
Disadvantages:
own) into the language.P.S. Models one and two are used in many languages, including Go. In Go example, developers themselves are responsible for the incorrect use of shared memory.
Beta Was this translation helpful? Give feedback.
All reactions