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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
