2010/3/22 Jille Timmermans <ji...@quis.cx> > 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) > > 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 > >
