> 2021年2月2日 上午11:04，tyson andre <tysonandre...@hotmail.com> 写道： > > Hi Aaron Piotrowski, > >> I would like to introduce an RFC for adding full-stack fibers to PHP: >> https://wiki.php.net/rfc/fibers >> >> Fibers are primarily used to implement green-threads or coroutines for >> asynchronous I/O. Fibers are similar to threads, except fibers exist within >> a single thread and require cooperative scheduling of the fibers by the >> process. Since fibers do not require a full CPU context switch, they are >> lightweight and more performant than multi-processing or threading for >> awaiting I/O. >> >> An implementation as an extension is at https://github.com/amphp/ext-fiber >> >> Fibers are a complex feature. The RFC contains many examples and links to >> code using fibers to help explain and demonstrate what is possible, however >> I’m certain many more questions and concerns will arise. Looking forward to >> feedback and discussion. > > I took a look at the amphp/ext-fiber repo a few weeks ago - nothing stood out > as a major concern but I'm only moderately familiar with threading, > A minor comment is that it'd be easier to read the phpt test cases if the > `--EXPECTF--` > section included the file's basename in the test output of error traces > instead of just `%s`, etc. > (e.g. tests/002-throw.phpt) > > ``` > Stack trace: > #0 %s(%d): {closure}() > #1 %s(%d): Loop->tick() > #2 %s(%d): Loop->run() > ... > ``` > > I didn't see in the test cases/rfc: > How do the `zend_try`/`zend_catch`/`zend_end_try` macros and > `zend_error_noreturn` macros get handled after a fatal error? > I'm not 100% sure - I think those use setjmp/longjmp internally - will fatal > errors continue to work if there's a fatal error from within a fiber. > (e.g. `require_once` on a file with a compile-time fatal error such as > duplicate parameters). > I forget exactly how they work, e.g. in the context of a web server before > this RFC - at a glance I'd guess an unrecoverable fatal error would cause the > worker to shut down. > Would being in a different fiber and different C stack interfere with the > shutdown process for fatal errors? (I guess the macros could be changed to > make that switch to the main fiber if needed to fix that) > > Thanks, > -Tyson Andre > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Hi Tyson Andre, We have tried two different solutions in Swoole to solve this issue. Since each coroutine has an independent C stack and the C stack location saved by bailout is illegal in other coroutines, we have to redundantly do zend_try and zend_catch in each coroutine. When a fatal error occurs, jump to the C stack corresponding to main(), and then exit through the normal process of PHP. However, this method is not a hundred percent safe. It is difficult for Swoole to recycle other surviving coroutines. In extreme cases, some memory problems may still occur. I prefer the other one - Due to the great efforts made by PHP8, the fatal errors in PHP have been greatly reduced and replaced by exception mechanisms. Therefore, when fatal errors occur in an extremely low possibility, directly exit through exit() may be the safest way. Of course, this will cause register_shutdown_function to fail. Regards, Twosee -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
