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
