Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47446
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.134 as permitted sender)
To: troels knak-nielsen <troelskn@gmail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <98b8086f1003220751j73a8414es89b9b469c46f6630@mail.gmail.com>
References: <98b8086f1003220751j73a8414es89b9b469c46f6630@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Organization: php.net
Date: Mon, 22 Mar 2010 16:14:12 +0100
Message-ID: <1269270852.1575.141.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution
 time exceeded"
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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.

johannes