Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113064 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 37126 invoked from network); 3 Feb 2021 16:19:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Feb 2021 16:19:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6060E1804DD for ; Wed, 3 Feb 2021 08:03:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RDNS_DYNAMIC,T_SPF_HELO_TEMPERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from qq.com (out203-205-221-173.mail.qq.com [203.205.221.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 3 Feb 2021 08:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1612368160; bh=lrwX5Y26HJO27p4xz2z/Gid5Glqam4gaaY0Do7TZAy4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=uOJ8ak+CCnCLWeWarJ8I2g8CaKXMwwXFkhKjRtbDd67P8RGvx24vhe/S9erfhTRhZ TU2l5AlxcgStD3p/DMZaruBmoy6SYJTn7+lz5NxP1LlxM3wBjaz9D1BEvnL9vu4hhT TqnuCrjq3RkC8R0Q6dTJ3/vAMFP9T0U6lm4JIKs8= Received: from [127.0.0.1] ([115.211.227.208]) by newxmesmtplogicsvrszc6.qq.com (NewEsmtp) with SMTP id A490EDF; Thu, 04 Feb 2021 00:02:36 +0800 X-QQ-mid: xmsmtpt1612368156ticw0v3bw Message-ID: X-QQ-XMAILINFO: OGprY/X9PNjVaGBn7RQAiLwNzXEEcOC99GmK5cvAUyjDncdonWWuIIXP2+/YEC Ju+VM/do9dYw/YoPZfdecjwQgM920vS1XJmjHxVJ+4Ra/SZDfXVLED0/lI75TJubEGGZgWtLPe0t ogKy+1QuEKEnTfez5XHIaxXcdOJ65+kctGCLZA5oPlZCfHrUosFFs593+YVK/ZyohG98rHCRyOVp gb1YxPmglvuedwbekBUwhyVQGRebs+TsKKLD7kMormwm1q+CjakDn+VkbVFrf9whsJXbW+Fq4BbC ClI+bPPyIdD3tZI0iTD9ugl/0KYzkszc9Q1hfz7dRsVgKWBRrip7mu4wuyOZbZZEHavQomEZYtHD g/tLJLhyITvCldDj4IWzDDPDi2PBZTgMpBuxmayMGAcNCOkshPYil0jPwOt3stf25vR8oNh4Qy++ zW8vGbJ7CCxio4jzysRwly8LjWkBzvMGzJpw9KxM4ZuJiWc82GYpAxVFdit/Vv2i2XjZ5rQ+uFCK 59mwkqn3rCoflK3m3F7tKU/lZ4JOP0e/vzShCNEFyGpeV853ei10STHdbc4zFDJAjNPXl/aHqagw 9OZwS5WAsmqoJWcgw8D9ahjdGelytmqstEp3Fu++g6WUoll0eOVv6E6FkPZ9Vg94g0BgWJYfWsS7 tKXlGgT5bvs40c1BwNOHGl4iA295qP1/jxlu3RiFZLNGWnrxw/EfiMlo8ayWdwTMtpX/bnETmln8 9OGQH4FkovcNG8Y8goTGPGsKIN6RQyMH46 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) In-Reply-To: Date: Thu, 4 Feb 2021 00:01:59 +0800 Cc: Aaron Piotrowski , php internals Content-Transfer-Encoding: quoted-printable X-OQ-MSGID: <07CD33A4-8D40-4A84-9F2A-7FECDF143293@qq.com> References: To: tyson andre X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [PHP-DEV] [RFC] Fibers From: twose@qq.com (twosee) > 2021=E5=B9=B42=E6=9C=882=E6=97=A5 =E4=B8=8A=E5=8D=8811:04=EF=BC=8Ctyson = andre =E5=86=99=E9=81=93=EF=BC=9A >=20 > Hi Aaron Piotrowski, >=20 >> I would like to introduce an RFC for adding full-stack fibers to PHP: = https://wiki.php.net/rfc/fibers >>=20 >> 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. >>=20 >> An implementation as an extension is at = https://github.com/amphp/ext-fiber >>=20 >> 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=E2=80=99m certain many more questions and concerns = will arise. Looking forward to feedback and discussion. >=20 > 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) >=20 > ``` > Stack trace: > #0 %s(%d): {closure}() > #1 %s(%d): Loop->tick() > #2 %s(%d): Loop->run() > ... > ``` >=20 > 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) >=20 > Thanks, > -Tyson Andre >=20 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >=20 >=20 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=