RE: [PHP-DEV] Safe timeout handling

From: Date: Thu, 21 Apr 2016 11:14:04 +0000
Subject: RE: [PHP-DEV] Safe timeout handling
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-92591@lists.php.net to get a copy of this message
Hi Dmitry, > -----Original Message----- > From: Dmitry Stogov [mailto:dmitry@zend.com] > Sent: Wednesday, April 20, 2016 12:58 PM > To: Nikita Popov <nikita.ppv@gmail.com>; Rasmus Lerdorf > <rasmus@lerdorf.com>; Anatol Belski <ab@php.net>; Antony Dovgal > <antony.dovgal@gmail.com>; Zeev Suraski <zeev@zend.com>; Xinchen Hui > <laruence@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

« previous php.internals (#92591) next »