Re: [VOTE] True Async RFC 1.6

Hello > This could be quite problematic for internal objects that might depend on global that will > switch. Yes, this will require changes to the PHP Engine, and we will have to determine their scope. > Something like this should be done explicitly through channels otherwise it would be quite > strange semantically for users. Yes, exactly, channels are an excellent way to explicitly pass objects between coroutines. But thanks to the ownership policy, the developer gains the ability to explicitly clone an object before passing it. Example: ```php function x(own object $y): void { } $var = new Obj(); $var2 = $var; x($var); // error: can't move object to x, because refcount > 1 x(clone $var); // yes it's possible ``` > I think it should be the only allowed case. Of course > The context switches will likely become more expensive but should be still cheaper than long > IO. I don’t know. To answer this question, we need to write code. But I hope it’s possible to find an optimization that has almost no performance impact. To solve this problem, one important change is needed: removing static var from opcodes. This would make it possible to share PHP opcodes between N threads as a readonly structure. I can’t say how feasible this task is. But if it is feasible, it opens the door to the third memory model (shared nothing). But as you understand, this approach provides the maximum possible level of protection. > This is still limited and supports only basic ops but I plan to add more ops Yes, this will give additional capabilities for the Reactor. I can see that libUV isn’t in much of a hurry to implement them. --- Ed