Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47450
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain quis.cx from 82.94.237.14 cause and error)
Message-ID: <4BA79025.9030708@quis.cx>
Date: Mon, 22 Mar 2010 16:43:33 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@php.net>
CC: troels knak-nielsen <troelskn@gmail.com>,
        PHP Developers Mailing List <internals@lists.php.net>
References: <98b8086f1003220751j73a8414es89b9b469c46f6630@mail.gmail.com> <1269270852.1575.141.camel@guybrush>
In-Reply-To: <1269270852.1575.141.camel@guybrush>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution time
 exceeded"
From: jille@quis.cx (Jille Timmermans)

Op 22-3-2010 16:14, Johannes Schlüter schreef:
> On Mon, 2010-03-22 at 15:51 +0100, troels knak-nielsen wrote:
>    
>> We log all errors that happens in our production environment, but as
>> fatal errors can't be handled from within php, we end up with little
>> information to go on for further debugging. I'm not very familiar with
>> the php internals code, but I managed to throw in a hack that appears
>> to work. In the handler function for timeouts (zend_timeout), I raise
>> a WARNING, sleep for 1 second and then resume normal behavior, which
>> results in a fatal error. This gives userland code 1 second to log the
>> error somewhere, which should be sufficient for debugging.
>>      
> A one second delay is no option there. And what actually happens is that
> the warning triggers your custom error handler. After that it sleeps
> then it dies.
>
> This also creates a "nice" way to extend the script runtime after the
> timeout occurred. aka. making the timeout useless for many scenarios it
> was meant for.
>    
This could be made configurable. Shared hosting providers probably want 
to disable the 'overriding' of the timeout. At my work; all code is 
written by our own developers; so there's no evil in there ;) (And it 
would be usefull to give extra debugging information)

-- Jille
> johannes
>
>
>
>