| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| rfc:max_execution_wall_time [2020/12/13 00:15] – kocsismate | rfc:max_execution_wall_time [2020/12/13 00:24] – kocsismate |
|---|
| A limitation of the implementation is that the timeout takes into effect on a best-effort basis, meaning that the fatal error is triggered only after the call exceeding the time limit is finished. This is in line with the current timeout behavior, and the RFC considers this as an acceptable limitation. | A limitation of the implementation is that the timeout takes into effect on a best-effort basis, meaning that the fatal error is triggered only after the call exceeding the time limit is finished. This is in line with the current timeout behavior, and the RFC considers this as an acceptable limitation. |
| |
| Furthermore, there is a question in case of platforms which already measure ''max_execution_time'' based on wall-clock time. The most notable of such systems is definitely Windows, but IBM PASE and Cygwin are also affected, since they both only support real-time timers. The position of this RFC is that ''max_execution_wall_time'' should act as an "alias" of ''max_execution_wall_time'' on these platforms, so changing any of the settings in question would affect the same timer. | Furthermore, there is a question in case of platforms which already measure ''max_execution_time'' based on wall-clock time. The most notable of such systems is definitely Windows, but IBM PASE and Cygwin are also affected, since they both only support real-time timers. The position of this RFC is that ''max_execution_wall_time'' should act as an "alias" of ''max_execution_time'' on these platforms, so any changes to the settings in question would affect the same timer. |
| |
| Adding a ''set_time_limit()'' counterpart is out of scope of the current RFC. | Adding a ''set_time_limit()'' counterpart is out of scope of the current RFC. |
| HHVM solved the same problem by introducing the ''TimeoutsUseWallTime'' ini setting (https://github.com/facebook/hhvm/commit/9a9b42e3610cdf242f16ddb8936ce34adfa0be9e) in order to offer a way to change the meaning of ''max_execution_time'', while still (partially) remaining compatible with PHP. This made sense for a sister language, but in case of PHP itself, it seems to be an unnecessary complication which could result in weird issues. | HHVM solved the same problem by introducing the ''TimeoutsUseWallTime'' ini setting (https://github.com/facebook/hhvm/commit/9a9b42e3610cdf242f16ddb8936ce34adfa0be9e) in order to offer a way to change the meaning of ''max_execution_time'', while still (partially) remaining compatible with PHP. This made sense for a sister language, but in case of PHP itself, it seems to be an unnecessary complication which could result in weird issues. |
| |
| It would also be possible to directly change the behavior of ''max_execution_time'' to measure real execution time on all platforms, without any exceptions. This approach is rejected by the current RFC mainly due to its huge BC break, and the fact that a CPU-time based execution timeout is useful for a sanity check of the code itself (e.g. for making sure there are no infinite loops). | It would also be possible to directly change the behavior of ''max_execution_time'' to measure wall-clock time on all platforms. This approach is rejected by the current RFC mainly due to its vast BC break, and the fact that CPU-time based execution timeouts are useful as a sanity check of the code itself (e.g. for making sure there are no infinite loops). |
| |
| ===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== |