Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47454
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.216 as permitted sender)
DomainKey-Status: bad
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
         :cc:content-type;
        b=KL1VBqVgUodLAYP1rvaOSo6qPL1wG6T91UZDxBqWOkDtsvhtvsP55OHATwjKpDReJB
         +vkwgbHtFrsVtrlOTP0wKmAbOjeSSGQNUJaYpCtXeHeEXLczkzyD+OZfZaWAnPXcwC3x
         c0VyaqmBMtY4iOpHw5OZVLsdscrN9HBpC+hZQ=
MIME-Version: 1.0
In-Reply-To: <4BA79025.9030708@quis.cx>
References: <98b8086f1003220751j73a8414es89b9b469c46f6630@mail.gmail.com>
	 <1269270852.1575.141.camel@guybrush> <4BA79025.9030708@quis.cx>
Date: Mon, 22 Mar 2010 17:01:49 +0100
Message-ID: <b54d0abe1003220901q42baa639h61ee05fa49553740@mail.gmail.com>
To: Jille Timmermans <jille@quis.cx>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@php.net>, 
	troels knak-nielsen <troelskn@gmail.com>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0015174c0f288eeba7048265d04e
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution time 
	exceeded"
From: tyra3l@gmail.com (Ferenc Kovacs)

--0015174c0f288eeba7048265d04e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2010/3/22 Jille Timmermans <jille@quis.cx>

> Op 22-3-2010 16:14, Johannes Schl=C3=BCter 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 t=
o
> 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 usefu=
ll
> to give extra debugging information)
>
> If you mentioned it, it would be a good thing, to have a possibility to
control the execution time INCLUDING the time spent waiting for external
resources.
if you run
time php -r 'set_time_limit(5);`sleep 10`;echo "done";';
you will see what I'm talking about.

Tyrael

> -- Jille
>
>  johannes
>>
>>
>>
>>
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0015174c0f288eeba7048265d04e--