Hi Nikita, Something potentially worth pointing out (and assuming I'm inferring the > correct behavior here): If max_execution_wall_time is exceeded during an > internal function call (which seems quite likely, as that's where there is > the most potential for something to hang) and the function does not return > within hard_timeout seconds, then the a process abort will be triggered. > The hard_timeout is 2s by default. If any of the individual call timeouts > are >= 2s, then it's not unlikely that this situation occurs. >
Thanks for bringing this to my attention, I didn't realize this consequence. I'm wondering though if it would be a sane idea to use the current, CPU time based timer for hard_limit even when max_execution_wall_time times out? This way the process abort could be avoided in case of most functions in question, if I got it right. Nevertheless, I'll update the RFC with its relation to hard_timeout in the coming days. As I'd like to proceed with this RFC soon, I'd appreciate any review and constructive feedback. I have two questions for example: - Is the max_execution_wall_time really the best setting name we can come up with? What about something like max_execution_real_time? - Would anyone miss a set_wall_time_limit() function? Regards: Máté
