Re: [PHP-DEV] [RFC] Fiber support (again)

[吕海涛]

> On Feb 10, 2018, at 22:49, Niklas Keller  wrote:
> 
>> Hi, all,
>> 
>> I have updated the RFC https://wiki.php.net/rfc/fiber
>> 
>> changes list:
>> 
>> - introduce the `throw(Exception $exceptin)` API
>> - record issues discussed
> 
> What about my suggestion of making PHP's main() automatically a Fiber,
> which avoids Fiber::yield() being used outside of a Fiber, because
> everything is a Fiber?
> 
> This would require another continuation mechanism, as nothing has
> access to the automatically created main()-Fiber otherwise.
> 
> There would also need to be something that stops the script execution
> as soon as there's no non-suspended Fiber anymore.

As you pointed out, the main process cannot be a Fiber because it need to
schedule other fibers. 

> 
> Regarding the internal calls: A core dump / segfault in case of
> Fiber::yield() inside an internal function is unacceptable. It doesn't
> give the user any clue what's wrong. Instead, an exception could be
> thrown from Fiber::yield(), which just bubbles up then. Full support
> for internal functions could be added at a later point then.

It is impossible to solve this issue before we get a pure stackless Zend VM.

If this feature can be merged into PHP 7.3, we could introduce a new counter
to record the zend vm nested level. Every time you enter an internal call,
let zend increment the counter, and decrement it when out. 

When we create a fiber, we remember current vm nested level. When zend execute
Fiber::yield,it will throw an error if the current vm nested level is not
equal to the original one.

This feature cannot be implemented without changing the zend vm code base.

Maybe we could get a stackless zend vm in the feature. like the stackless python

https://github.com/stackless-dev/stackless

> 
> Regards, Niklas




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Don't add simple objects to GC's roots

[吕海涛]

Hi,
> On 26 Jul 2017, at 22:57, Nicolas Grekas  wrote:
> 
> There is a way to work around: just call gc_disable(). But this means
> dealing with side effects of the engine in userland. Moreover, this also
> means leaking memory, since meanwhile roots are not populated.

Maybe we could make gc_disable accept one reference zval as parameter, and
clear the GC_COLLECTABLE flag of zval.value->gc.u.v.flags. So, this zval 
will never be put into gc root list.



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php