Re: Safe timeout handling

On Wed, Apr 20, 2016 at 12:58 PM, Dmitry Stogov <dmitry@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