Hi Rowan and Peter, Tangentially, can this be considered a bug in FPM's handling? I appreciate > the speed boost FPM brought over CGI, but the more I work with it the less > I like the way it functions (but that is a separate conversation). >
No, I don't think so, since FPM terminates the child process by sending a SIGTERM (rather than a SIGKILL), it seems that it does the right thing based on the source code. But I'd appreciate it if someone more familiar with FPM or process management could verify my assumptions. Actually, this may be part of the confusion: I'm not sure what you're > referring to by "distributed systems", so don't know whether I'm > included in the set of developers you're picturing here. My definition of "distributed system" is when there is a network boundary between components of an application. Practically speaking, this is the case when the application code and the database/cache/sessions etc. are on different servers. So, again, it comes down to whether this is a "last resort" setting, or > something you'd expect to be invoked regularly. Yes, I certainly imagine it as a last resort possibility which could supersede FPM's "request_terminate_timeout" or the other external timeout mechanisms that are currently in use. In fact, "max_execution_wall_timeout" is not effective alone, it has to be used in cooperation with other timeout settings either on the caller (PHP) or the callee (e.g. database) side, since external calls cannot be cancelled midway by PHP. That said, setting cURL, socket etc. timeouts is still highly encouraged as a regular countermeasure. My purpose with this RFC is to improve the last safety net we have (real execution timeout), which I find suboptimal in its current form. You missed the key part of the quote you replied to here, which is > "return partial results". My point was not about the *formatting* of the > error, but that its *content* might need to be application-specific. Ah, sorry, I did really miss it! I think my answer still holds though: if there is such a requirement, developers can ignore this ini setting (or explicitly set its value to 0, if necessary). Probably this is a good example why we should not make wall-clock time based measurement the default of "max_execution_time". Otherwise, I think my proposal would offer a solution for the 90% of the problems we currently have due to the way how "max_execution_time" works. It might be useful to expand on this in the RFC, remembering that > "RSHUTDOWN" doesn't mean anything to a userland developer. Will > "finally" blocks be run? Destructors? Will the error handler be invoked? > I know the answers are probably "the same as the current timeout > setting", but spelling it out would help to picture when this feature > might or might not be useful. I absolutely agree, and I'll try to elaborate as soon as I touch the RFC again, most probably today. Your answer is true, it is "the same as the current timeout setting". However, I was considering the possibility to throw an exception in case of the new timeout, but I think this task would be more suitable for a PHP 9.0 release where we could convert fatal errors to exceptions where it would make sense. Máté
