Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92559
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.116.18 as permitted sender)
Message-ID: <BLU436-SMTP92E8D85E416AE9B0841A2E26D0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_35438A52-8786-43E5-8417-8C15F3AEA06B"
MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <5717ACAF.8000703@zend.com>
Date: Wed, 20 Apr 2016 19:40:05 +0200
CC: Dmitry Stogov <dmitry@zend.com>,
 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>,
 internals <internals@lists.php.net>
References: <BY2PR0201MB1784CF39602D523115E594A6BF6D0@BY2PR0201MB1784.namprd02.prod.outlook.com> <59CCDF7AE84348429CD37A2A878B29C8@pc1> <5717ACAF.8000703@zend.com>
To: Matt Wilmas <php_lists@realplain.com>
Subject: Re: [PHP-DEV] Safe timeout handling
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_35438A52-8786-43E5-8417-8C15F3AEA06B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"


> Am 20.04.2016 um 18:22 schrieb Dmitry Stogov <dmitry@zend.com>:
>=20
>=20
>=20
> On 04/20/2016 06:24 PM, Matt Wilmas wrote:
>> Hi Dmitry,
>>=20
>> ----- Original Message -----
>> From: "Dmitry Stogov"
>> Sent: Wednesday, April 20, 2016
>>=20
>>> Hi,
>>>=20
>>>=20
>>> It's a well known PHP problem, that exceeding of execution time-out
>>> (max_execution_time) may lead to unexpected crashes.
>>>=20
>>> They occur because PHP may be interrupted in inconsistent state, and =
attempt
>>> to release allocated by request resources leads to failure.
>>>=20
>>> Almost any big site sees these crashes from time to time.
>>>=20
>>>=20
>>> I propose to delay actual request termination until a "safe" point =
in
>>> interpreter.
>>>=20
>>> Signal handler will just set EG(timed_out) flag.
>>>=20
>>> Interpreter will check this time from time to time (on jumps and =
calls that
>>> may make loops or recursion) and perform the actual termination.
>>>=20
>>> This approach already works in PHP for Windows.
>>=20
>> I was thinking about this, checking for things like EG(exception) =
"constantly," a few months ago for another reason...
>=20
> This is a bit different problem. We can't delay EG(exception) checks. =
I thought about a better way of exception handing but didn't find =
anything usable and portable.
>>=20
>> What about instead of adding additional checks in the same place(s) =
in VM, we just limit it to 1 check, for multiple things? Just have =
EG(something_unexpected_to_check), and behind that (or in a function, I =
guess), the actual rare/unexpected thing gets checked: timed_out, =
exception, etc.
>=20
> Yes, I have the same idea in background. I even wrote: The same =
"interrupt" handling mechanism in the future may be reused for TICK
> and signal handling.
>=20
>>=20
>> It seems Bob had a similar idea in the PR comment, except literally =
using exceptions...
>>=20
>>> In addition I introduce hard_timeout (default value 2 seconds).
>>>=20
>>> 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.
>>>=20
>>> ZTS build will ignore "hard_timeout" (in the same way as PHP on =
Windows do).
>>>=20
>>>=20
>>> The PR: https://github.com/php/php-src/pull/1876
>>>=20
>>>=20
>>> It removes "exit_on_timeout" ini directive, and introduces =
"hard_timeout"
>>> instead.
>>>=20
>>> Additional checks in VM make 0.5-1% slowdown in term of instruction =
retired
>>> reported by callgrind.
>>=20
>> A single check would save those additional instructions and branches, =
and would actually improve things on Windows (since this PR doesn't =
change anything there).
>=20
> If you or Bob show me a better working solution (or just PoC), I'll be =
only happy with this.

I looked at it; if we had an already existing if (EG(exception)) branch =
there, we could actually save something, but Dmitry put it just in =
jumping ops, where we never have an exception check. (And there we need =
a check as else a while(1) {} would never be timed out - i.e. when there =
are no ops inside which actually do a check_exception) =85 so this =
EG(something_unexpected_to_check) is even more expensive.

Things would be easy if we could just alter the return addresses of the =
opcode handlers or similar magic, but I doubt that's a very nice =
cross-platform solution...

If you have an even better idea than I do=85 please show a PoC :-)

Thanks,
Bob

> Thanks. Dmitry.
>>=20
>>=20
>>> I think we don't need RFC for this. This is a long time desired fix.
>>>=20
>>>=20
>>> The same "interrupt" handling mechanism in the future may be reused =
for TICK
>>> and signal handling.
>>>=20
>>>=20
>>> Thanks. Dmitry.
>>=20
>> - Matt


--Apple-Mail=_35438A52-8786-43E5-8417-8C15F3AEA06B--