Hi Dmitry, > -----Original Message----- > From: Dmitry Stogov [mailto:dmi...@zend.com] > Sent: Wednesday, April 20, 2016 12:58 PM > To: Nikita Popov <nikita....@gmail.com>; Rasmus Lerdorf > <ras...@lerdorf.com>; Anatol Belski <a...@php.net>; Antony Dovgal > <antony.dov...@gmail.com>; Zeev Suraski <z...@zend.com>; Xinchen Hui > <larue...@php.net> > Cc: internals <internals@lists.php.net> > Subject: [PHP-DEV] Safe timeout handling > > 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. > I've tested your patch with CLI, mpm_prefork, mpm_worker and mpm_winnt and see no regressions. The existing tests in tests/*/*timeout*.phpt pass as well. We'd probably need to add some more with respect to the new INI option and more extensive testing under high load.
AFM it's a good step towards unifying the timeout handling and making it safer. Even better if ticks and exceptions handling can be later improved by the same approach. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php