RE: [PHP-DEV] Safe timeout handling
| From: | Anatol Belski | 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