On Wed, Apr 20, 2016 at 12:58 PM, Dmitry Stogov <dmi...@zend.com> wrote: > 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. > > > 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. > > 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.
Hi ! Good new. No RFC needed, but that breaks ABI and could impact extensions. So, 7.1 as target is OK, not 7.0 Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
