Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92551 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59710 invoked from network); 20 Apr 2016 15:24:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Apr 2016 15:24:05 -0000 Authentication-Results: pb1.pair.com header.from=php_lists@realplain.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php_lists@realplain.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain realplain.com from 68.114.190.30 cause and error) X-PHP-List-Original-Sender: php_lists@realplain.com X-Host-Fingerprint: 68.114.190.30 mtaout005-public.msg.strl.va.charter.net Received: from [68.114.190.30] ([68.114.190.30:51416] helo=mtaout005-public.msg.strl.va.charter.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 16/DD-14036-31F97175 for ; Wed, 20 Apr 2016 11:24:04 -0400 Received: from impout002 ([68.114.189.17]) by mtaout005.msg.strl.va.charter.net (InterMail vM.9.00.021.00 201-2473-182) with ESMTP id <20160420152401.UCBQ7222.mtaout005.msg.strl.va.charter.net@impout002>; Wed, 20 Apr 2016 10:24:01 -0500 Received: from pc1 ([97.87.188.16]) by impout002 with charter.net id kfQ01s00K0Mfu3D01fQ0Hr; Wed, 20 Apr 2016 10:24:01 -0500 X-Authority-Analysis: v=2.1 cv=EbdGQZWC c=1 sm=1 tr=0 a=Ay788ph35uAhBIV2K373vw==:117 a=Ay788ph35uAhBIV2K373vw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=8nJEP1OIZ-IA:10 a=NEAV23lmAAAA:8 a=90hQnw-symoBlKgc-0AA:9 a=wPNLvfGTeEIA:10 Message-ID: <59CCDF7AE84348429CD37A2A878B29C8@pc1> To: "Dmitry Stogov" , "Bob Weinand" , "Nikita Popov" , "Rasmus Lerdorf" , "Anatol Belski" , "Antony Dovgal" , "Zeev Suraski" , "Xinchen Hui" Cc: "internals" References: Date: Wed, 20 Apr 2016 10:24:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [PHP-DEV] Safe timeout handling From: php_lists@realplain.com ("Matt Wilmas") Hi Dmitry, ----- Original Message ----- From: "Dmitry Stogov" Sent: Wednesday, April 20, 2016 > Hi, > > > It's a well known PHP problem, that exceeding of execution time-out > (max_execution_time) may lead to unexpected crashes. > > They occur because PHP may be interrupted in inconsistent state, and > attempt > to release allocated by request resources leads to failure. > > Almost any big site sees these crashes from time to time. > > > I propose to delay actual request termination until a "safe" point in > interpreter. > > Signal handler will just set EG(timed_out) flag. > > Interpreter will check this time from time to time (on jumps and calls > that > may make loops or recursion) and perform the actual termination. > > This approach already works in PHP for Windows. I was thinking about this, checking for things like EG(exception) "constantly," a few months ago for another reason... What about instead of adding additional checks in the same place(s) in VM, we just limit it to 1 check, for multiple things? Just have EG(something_unexpected_to_check), and behind that (or in a function, I guess), the actual rare/unexpected thing gets checked: timed_out, exception, etc. It seems Bob had a similar idea in the PR comment, except literally using exceptions... > In addition I introduce hard_timeout (default value 2 seconds). > > In case the "soft" timeout wasn't handled "safely" in that 2 seconds > (because of long running internal function), PHP process will be > terminated > without attempt to free any resources. > > ZTS build will ignore "hard_timeout" (in the same way as PHP on Windows > do). > > > The PR: https://github.com/php/php-src/pull/1876 > > > It removes "exit_on_timeout" ini directive, and introduces "hard_timeout" > instead. > > Additional checks in VM make 0.5-1% slowdown in term of instruction > retired > reported by callgrind. A single check would save those additional instructions and branches, and would actually improve things on Windows (since this PR doesn't change anything there). > I think we don't need RFC for this. This is a long time desired fix. > > > The same "interrupt" handling mechanism in the future may be reused for > TICK > and signal handling. > > > Thanks. Dmitry. - Matt