> but it would be interesting to replace the scheduler with something that > utilized go-routines for true multi-threading. Whether that works or not, > is a whole different can of worms. > > — Rob > If the question is whether it is possible to interact with a PHP thread from another thread by sending an event to the Reactor, the answer is yes, it is possible. Moreover, from the PHP-land side, this could be a Channel.
If the question is deeper — replacing the Scheduler with a Scheduler in another language or from a different ecosystem — then it is more likely possible than not, considering that the module itself is separated from the rest of the implementation. If you know a situation where this would be useful, then why not. For example, in cases of integration with a web server, we can just send a message through a channel from "server-thread" to "php-thread", and in a microtask written in C, for example, create Fibers to handle the request. This approach is used in Swoole. And this solution should be even slightly faster than in Swoole because the interaction will occur through memory copying within a single process. If memory copying is to be avoided, then the web server can be integrated directly into the Reactor, making the web server itself run as a microtask. Since the memory will be allocated immediately in the correct thread, there won’t even be a need to copy it, which in some cases might provide a performance boost. Or maybe not... Ed.
