> You might want to look to parallel extension as it's already dealing > with that and mostly works - of course combination with coroutines will certainly complicate it but the point is that memory is not shared.
Do you mean this extension: https://www.php.net/manual/en/book.parallel.php? Yes, I studied it before starting the development of True Async. My very first goal was to enable, if not coroutine execution across threads, then at least interaction, because the same thing is already possible with Swoole. However, parallel does not provide multitasking and will not be able to in the future. The best it can offer is interaction via Channel between two different threads, which will be useful for job processing and built-in web servers. And here's the frustrating part. It turns out that parallel has to copy PHP bytecode for correct execution in another thread. This means that not only does the memory manager need to be replaced with a multi-threaded version, but the virtual machine itself must also be refactored. For PHP to work correctly in multiple threads with context switching, it will be necessary to find a way to rewrite all the code that reads/writes global variables. (Where TLS macros are used, this shouldn't be too difficult. But is that the case everywhere?) This applies to all extensions, both built-in and third-party. Such a language update would create an "extension vacuum." When a new version is released, many extensions will become unavailable due to the need to adapt to the new multitasking model. > I didn't really mean to introduce it as part of this RFC. > What I meant is to design the API so there is still possibility to add it in the future without risking various race condition in the code. > It means primarily to put certain restrictions that will prevent it like limited access to global and passing anything by > reference (including objects) to the running tasks. Primitives like *Context* are unlikely to be the main issue for multitasking. The main problem will be the code that has been developed for many years with single-threaded execution in mind. This is another factor that raises doubts about the rationale for introducing real multitasking in PHP. If we are talking about a model similar to Python’s, the current RFC already works with it, as a separate thread is used on Windows to wait for processes and send events to the PHP thread. Therefore, integrating this RFC with parallel is not an issue. It would be great to solve the bytecode problem in a way that allows it to be freely executed across different threads. This would enable running any closure as a coroutine in another OS thread and interacting through a channel. If you talk about this functionality, it does not block concurrency or current RFC. This capability should be considered as an additional feature that can be implemented later without modifying the existing primitives. While working on this RFC, I also considered finding a way to create SharedObject instances that could be passed between threads. However, I ultimately concluded that this solution would require changes to the memory manager, so these objects were not included in the final document. Ed.
