Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115581
MIME-Version: 1.0
Date: Sun, 25 Jul 2021 13:43:36 +0200
Message-ID: <CADK1yX+0A4teqwBHaWiTYG0inBkbmAS9+aRM5a6qHgwz1XvE+g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c0490c05c7f12726"
Subject: [RFC] Wall clock time based execution time
From: deleugyn@gmail.com (Deleu)

--000000000000c0490c05c7f12726
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello everyone!

A few months ago there was a proposed RFC for having wall clock time for
timeout [1]. It seemed like there was not a lot of push back against it [2]
with an exception of Nikita's comment about having 2 ini settings vs having
a toggle on the existing ini setting [3]

[1] https://wiki.php.net/rfc/max_execution_wall_time
[2] https://externals.io/message/112492#113210
[3] https://github.com/php/php-src/pull/6504#issuecomment-743064911

The reason I'm bringing this up is because I'm interested in the
possibility of having this functionality in PHP as a potential solution for
serverless environment hard limits. The number #1 issue with running PHP on
AWS Lambda via Bref is caused by API Gateway having a hard limit of 30
seconds. When combining that with the fact that AWS Lambda inside VPC loses
internet connectivity (unless a NAT Gateway / NAT Instance exists in the
VPC), it's extremely common to have code attempting to connect to a
database, make an API call or try to upload data into S3 and get confronted
with Server Error - Task timed out. This gets aggravated by the fact that
we have no opportunity to flush out logs, meaning any attempt to write logs
to stderr is simply lost and it makes it an arduous task to debug.

I did a quick testing around register_shutdown_function and it seems to
provide what we need if we had wall time-based timeout.

```
<?php

ini_set('max_execution_time', 3);

register_shutdown_function(function () {
    echo 'Moment 1: we have an opportunity for flushing out stderr' .
PHP_EOL;

    while(true) {
        // curiously this will run for an extra 2 seconds and throw another
fatal error.
    }
});

echo 'Moment 0: script is very early' . PHP_EOL;

while (true) {
    // this will run for 3 seconds and throw a fatal error.
}
```

Essentially the end goal is to be able to set PHP timeout smaller than the
external environment (e.g. 27 seconds PHP vs 30 seconds API Gateway) and
have an extra 2 seconds worth of time to help users see their logs,
debugging backtrace and/or line of code where the exception was thrown.
This would help immensely to diagnose general timeout issues.

I understand that the use case described may be too niche (AWS being a
single vendor), but given that there was not much push back 7 months ago,
perhaps my email can be interpreted as just yet another huge benefit the
serverless community would have if such a feature could be introduced to
PHP.

Is there anything I can do to help bring that RFC to a vote for PHP 8.2?
--=20
Marco Aur=C3=A9lio Deleu

--000000000000c0490c05c7f12726--