Hi > I don't have any specific use-cases in mind. I'm just trying to be > forward-looking here. But what is clear is that some people would like to see > async/await in PHP. This RFC would ostensibly be a > step towards that. All I'm trying to do is make sure that it doesn't put up > roadblocks for future enhancements. >
The main obstacles to multithreading are: * The state of the PHP virtual machine, as well as how the bytecode is stored (some elements cannot be transferred) * The memory manager * The garbage collector Of course, for a multithreaded version, the scheduler would have to be almost completely rewritten, but this task doesn’t seem as demanding as the ones above. As for the RFC itself, it does not impose any additional limitations beyond those already inherent to PHP. If coroutines can be moved between threads, then all variables must be thread-safe. How will that be guaranteed? The context of a `Closure` must also be thread-safe, how will that be ensured? All these questions are outside the scope of this RFC and relate to the implementation of closures. There is another risk here. If PHP introduces async functionality that works within a single thread, users will start writing code with closures, assuming it will work correctly because everything runs in one thread. The RFC does not regulate this at all, and that’s the problem. Developers will begin writing code designed for single-threaded behavior. If multithreading is later introduced, that code will inevitably break. There’s much more that could be added here. The main point is that the RFC is not designed around a memory model for parallelism, and such a model should not be part of the RFC. If you’re planning such changes for PHP, it would be wise to come up with a way to handle them. But to do that, we first need to understand which memory model you’ll choose. Will it be Actors + SharedState, meaning special kinds of closures, or something else? > Second: it should be emitting either a stream of files, or a stream of arrays > of files. Returning list<File>|File is not a great pattern. I wasn’t suggesting doing that, I just wanted to show the difference between “multiple values” and “a single value.” > That's the first review thread for Swift's Structured Concurrency proposal. > The proposal itself is here, along with links to the three pitch and three > review threads, and the async/await and actor proposals: Thank you. I will look at it. > Why is the protect function needed, then? If you request cancellation, the > coroutine is free to ignore the cancellation and run to completion. That's > what makes it cooperative. Because cancellation interrupts coroutine waiting. If cancellation occurs deep within the runtime while it is writing a buffer to a socket, it means that not all data will be written. That’s exactly the case where protect is useful. ---- Thanks, Ed.
