Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51643 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 32210 invoked from network); 9 Mar 2011 15:59:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2011 15:59:05 -0000 Authentication-Results: pb1.pair.com header.from=landeholm@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=landeholm@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: landeholm@gmail.com X-Host-Fingerprint: 209.85.214.170 mail-iw0-f170.google.com Received: from [209.85.214.170] ([209.85.214.170:43372] helo=mail-iw0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1C/69-21312-8C3A77D4 for ; Wed, 09 Mar 2011 10:59:05 -0500 Received: by iwn3 with SMTP id 3so680948iwn.29 for ; Wed, 09 Mar 2011 07:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wOEBZAAY3wierUCmpymX9OQces9DsVQo9vcAEgXQW+Y=; b=nCPTSxs7QeYQULVliAqMoffF6w6gVGzESO1RnZ0HOyof58LAECSLZL5rLTxWapaemk ViQRsEUU9Ov9/EYOD0cuxBUyYwLHx7QUS9D3LcGGckDIqDFUwcBLNJ5Qp7F3qiOZIEkV Pyi47mrkKhDrQ+uDWedyd73AOSrxXN8lYXDZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=P1iEXC4XNODIawwxalbCE8gKTtJn/0633Mp4w7J4RmcYDxooONgKodwtwlPwSECJG8 g7qCs5nwKKnLnGJFC1gRzht9OZB+7xYts8JVxu6HrAT04Wbh8tevN7rwnlAAs7lLTkVk DBTXfTJpBxV0BPslG7Xi6hOgyJdfVuyQitqd0= MIME-Version: 1.0 Received: by 10.42.196.9 with SMTP id ee9mr7876577icb.21.1299686342575; Wed, 09 Mar 2011 07:59:02 -0800 (PST) Received: by 10.231.17.68 with HTTP; Wed, 9 Mar 2011 07:59:02 -0800 (PST) In-Reply-To: References: <4D7629B5.4090007@php.net> <4D76D849.6000103@gmail.com> <4D778E63.2060504@gmail.com> Date: Wed, 9 Mar 2011 16:59:02 +0100 Message-ID: To: Ferenc Kovacs , internals@lists.php.net Content-Type: multipart/alternative; boundary=20cf303bfffcc4c589049e0ecef7 Subject: Re: [PHP-DEV] Make set_time_limit() timeout a catchable fatal error From: landeholm@gmail.com (Hannes Landeholm) --20cf303bfffcc4c589049e0ecef7 Content-Type: text/plain; charset=ISO-8859-1 No you can't gracefully handle all fatal errors. The shutdown function will be called after *some* fatal errors but not all of them. See the bug I reported here for more information: http://bugs.php.net/bug.php?id=54195 ~Hannes On 9 March 2011 16:12, Ferenc Kovacs wrote: > 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 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 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 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 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 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 >>>> > >>>> > >>>> >>> >>> >> > --20cf303bfffcc4c589049e0ecef7--