Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51640
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=rBcpqlQJAurJ2pwAUVW6Gpf5+QWmmNgWU6FehtMJbcCWsxFdjmIxWQeNn7BbhPVNdu
         y/JhFT7hXSHuJ2Czzn8IDKaNHK1JETqQ6bOgs0UE7Wz10pW2UVd80zECNSfsUKeyNhcc
         JcW20u+vfkuAZHuxUhgnzimTt6cJpO7mR48Zc=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <AANLkTimTqEUYfn6e+e9PAD-5kUi4-+CR5rh6DWWt36mi@mail.gmail.com>
References: <4D7629B5.4090007@php.net>
	<AANLkTinRyVatARH4SUiXCaJCOAzxTP5fHsU2PLvwx3Sy@mail.gmail.com>
	<4D76D849.6000103@gmail.com>
	<AANLkTimNLUOsHMVHSDBKHy2EaH40Akgdc-0n7b4EpOk9@mail.gmail.com>
	<4D778E63.2060504@gmail.com>
	<AANLkTi=aebP=vEYFdUnZQZ_CxfFW2Ai=4G=ksKXUA1bu@mail.gmail.com>
	<AANLkTimpH-bRbk8rua_JuSNOHirGSFMgK5UP4HsbxDOE@mail.gmail.com>
	<AANLkTimTqEUYfn6e+e9PAD-5kUi4-+CR5rh6DWWt36mi@mail.gmail.com>
Date: Wed, 9 Mar 2011 16:12:07 +0100
Message-ID: <AANLkTikJmhCapLLLrsD0S6kpHGt3P99UVO6WW4P94a=f@mail.gmail.com>
To: Hannes Landeholm <landeholm@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307f3bb8fced81049e0e2658
Subject: Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error
From: info@tyrael.hu (Ferenc Kovacs)

--20cf307f3bb8fced81049e0e2658
Content-Type: text/plain; charset=UTF-8

FYI you can gracefully handle every error. even the non-recoverable ones.
if you check my library you can test it also, I have an example file for
every non recoverable error (E_PARSE, E_CORE_ERROR, etc.).

from my point of view, every userland error should be catchable from
userland.
the max execution time servers two purpose:
- it saves you from shooting you in the leg (will abort an infinite loop for
example)
- it could be used as a tool by the sysadmin to restrict the cpu usage in a
shared hosting environment.
the ability to execute code via register_shutdown_function after the
"Maximum execution time exceeded" fatal error thrown by the engine makes the
second point void (except if you disable the register_shutdown_function,
which you would do of course in a shared environment).

so I think that it should be only used for the first problem, in which case
it could be catchable IMO, because it doesn't leave the engine in an
unstable state.

Tyrael

On Wed, Mar 9, 2011 at 3:53 PM, Hannes Landeholm <landeholm@gmail.com>wrote:

> That's not a problem. Timeouts should be non-recoverable IMO as it's a
> serious problem and I think most PHP developers would agree with this.
> Making errors "recoverable" is difficult to implement, could have
> performance penalties and be conceptually wrong when the state is defined as
> "never allowed to happen".
>
> What I'm concerned about is that all problems should be able to be handled
> gracefully from the register_shutdown_function like showing an informative
> page, setting HTTP status, logging the problem, sending an error report,
> etc. Not all fatal errors can be caught this way, including script timeout.
>
> ~Hannes
>
>
> On 9 March 2011 15:39, Ferenc Kovacs <info@tyrael.hu> wrote:
>
>> no, it only means that you cant return to the original scope and continue
>> the execution of your script.
>> as you can't throw exceptions also, because your code is running without a
>> stack frame.
>> you can check out the https://github.com/Tyrael/php-error-handler its a
>> little class which operates with register_shutdown_function to allow
>> handling non-recoverable errors before halting.
>> there are too many case in the php src where non-recoverable errors are
>> triggered for non fatal problems.
>> that should be changed, so open a bugreport if you think you found one,
>> where isn't neccessary to halt the execution.
>>
>> Tyrael
>>
>>
>> On Wed, Mar 9, 2011 at 3:30 PM, Hannes Landeholm <landeholm@gmail.com>wrote:
>>
>>> You mean the shutdown function is called and 1 nanosecond later PHP
>>> crashes
>>> so you don't have time to do anything?
>>>
>>> ~Hannes
>>>
>>> On 9 March 2011 15:27, David Muir <davidkmuir@gmail.com> wrote:
>>>
>>> > Hmm, I think I worded that poorly.
>>> > A function registered with register_shutdown_function does execute when
>>> > the max_execution_time is exceeded.
>>> > What it doesn't let you do is to recover in the same way an error
>>> > handler would let you.
>>> >
>>> > David
>>> >
>>> > On 09/03/11 22:56, Hannes Landeholm wrote:
>>> > > I second making time limit reached catchable. All non catchable fatal
>>> > errors
>>> > > are a problem for me. I need to handle problems gracefully to ensure
>>> the
>>> > > stability of production systems instead of PHP just killing itself
>>> > without
>>> > > warning. I just reported a similar issue:
>>> > > http://bugs.php.net/bug.php?id=54195
>>> > >
>>> > > A simple way to implement this would be to register a function that
>>> would
>>> > be
>>> > > called N seconds before the script would timeout.
>>> > >
>>> > > register_timeout_handler(2, function() { die("PHP timed out."); });
>>> > >
>>> > > It would be called just as a shutdown function - in fact I'd like to
>>> use
>>> > the
>>> > > same function as my shutdown function and get the error with
>>> > > error_get_last(). Of course set_time_limit(0) could be used in this
>>> > function
>>> > > to prevent the timeout of the timeout handler. This does not
>>> "prevent"
>>> > > timeout since set_time_limit could have been called by the script
>>> before
>>> > the
>>> > > timeout anyway.
>>> > >
>>> > > On that note I also miss a function which returns the time the script
>>> can
>>> > > keep running for. If that calculate needs to be calculated to
>>> implemented
>>> > to
>>> > > implement this, why not make the value available to the PHP script?
>>> > >
>>> > > ~Hannes
>>> > >
>>> > > On 9 March 2011 02:30, David Muir <davidkmuir@gmail.com> wrote:
>>> > >
>>> > >> Although it doesn't let you recover from a timeout, you could use
>>> > >> register_shutdown_function to gracefully exit after a fatal error.
>>> > >>
>>> > >> register_shutdown_function(function(){
>>> > >>    $error = error_get_last();
>>> > >>    if($error && $error['type'] === E_ERROR){
>>> > >>        echo 'PHAIL! Oh noes, something went wrong!';
>>> > >>        // do whatever else you need to do before quitting
>>> > >>    }
>>> > >> });
>>> > >>
>>> > >> Cheers,
>>> > >> David
>>> > >>
>>> > >> On 08/03/11 22:39, Pierre Joye wrote:
>>> > >>> hi,
>>> > >>>
>>> > >>> is not the goal of this setting to prevent that a script runs
>>> longer
>>> > >>> than a given time? A catchable error will prevent that to happen.
>>> > >>>
>>> > >>> On Tue, Mar 8, 2011 at 2:05 PM, Sebastian Bergmann <
>>> sebastian@php.net>
>>> > >> wrote:
>>> > >>>>  Could set_time_limit() be changed in such a way that it triggers
>>> a
>>> > >>>>  catchable fatal error instead of a fatal error? Thanks!
>>> > >>>>
>>> > >>>> --
>>> > >>>> Sebastian Bergmann                    Co-Founder and Principal
>>> > >> Consultant
>>> > >>>> http://sebastian-bergmann.de/
>>> > >> http://thePHP.cc/
>>> > >>>> --
>>> > >>>> PHP Internals - PHP Runtime Development Mailing List
>>> > >>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>> > >>>>
>>> > >>>>
>>> > >>>
>>> > >>
>>> > >> --
>>> > >> PHP Internals - PHP Runtime Development Mailing List
>>> > >> To unsubscribe, visit: http://www.php.net/unsub.php
>>> > >>
>>> > >>
>>> >
>>> >
>>> > --
>>> > PHP Internals - PHP Runtime Development Mailing List
>>> > To unsubscribe, visit: http://www.php.net/unsub.php
>>> >
>>> >
>>>
>>
>>
>

--20cf307f3bb8fced81049e0e2658--