Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112573
MIME-Version: 1.0
References: <CAH5C8xW981Fn91HsHmZfbLseXwSyOtM1X5u1zsAL4ofXhka=nw@mail.gmail.com>
 <CAEPJdumFUe53ccUwCib_xJFuMQAu1sYXg_3Me4umnSrxbPUS3w@mail.gmail.com>
 <CAH5C8xUAg3V8ELDJgDbj7qKhiNo3E3MfB4JnyWJxMe=AmBrbsw@mail.gmail.com>
 <9b36af8a-270f-2796-194e-b50296522407@gmail.com> <CAH5C8xWQbiLk-ov=B5B_wvxarFbD_dTSc0XhCUs4TmdLPErKGw@mail.gmail.com>
 <CAJvSBVNCHsGanSBgLZ6_Ysc8DS-_UH5jJFTY1XURtZ4OT_+SMg@mail.gmail.com>
In-Reply-To: <CAJvSBVNCHsGanSBgLZ6_Ysc8DS-_UH5jJFTY1XURtZ4OT_+SMg@mail.gmail.com>
Date: Mon, 21 Dec 2020 13:21:16 +0100
Message-ID: <CAH5C8xVsS+4HZT5sTPgFSvk3FUpdAOser3vgohm9f-prcX+g9w@mail.gmail.com>
To: Peter Bowyer <phpmailinglists@gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004aff7a05b6f87f6d"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Measuring maximum execution time
 based on wall-time
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000004aff7a05b6f87f6d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 les=
s
> 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 cas=
e
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=C3=A1t=C3=A9

--0000000000004aff7a05b6f87f6d--