Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112550
To: PHP Internals List <internals@lists.php.net>
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>
Message-ID: <4aaf2881-026a-0c65-b4a5-65c03bb09126@gmail.com>
Date: Fri, 18 Dec 2020 18:45:54 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <CAH5C8xWQbiLk-ov=B5B_wvxarFbD_dTSc0XhCUs4TmdLPErKGw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] [Discussion] Measuring maximum execution time
 based on wall-time
From: rowan.collins@gmail.com (Rowan Tommins)

Hi Máté,


On 18/12/2020 16:43, Máté Kocsis wrote:
> I think this is mostly not about application-level, rather than 
> infrastructure-level issues, at least
> according to our use-cases.


I think we may actually just be saying the same thing in different 
terms: in this message, you refer to a "heavy DOS attack", which I 
totally agree is the kind of scenario where "just kill some processes 
and hope that's enough to ride out the storm" would be useful.

Some of your earlier messages, though, made it sound like you were 
relying on it as an every day thing - you talked about seeing 
"regressions" during your migration, for instance. But maybe I just read 
too much into that wording?


> In my opinion, if the proposed ini setting causes consistency issues 
> for an application, then they are already
> vulnerable to other factors which can make their application halt 
> execution at random places: fatal errors, power outages,
> etc.


Certainly, I would *like* my application to be robust to a power outage 
in the middle of a request; but I would prioritise that robustness based 
on how likely it is to happen. If one request in a billion is terminated 
unexpectedly, I will probably take certain risks; if it's going to 
happen on a regular basis, I'm going to have to spend a lot more time on 
that set of problems.

So, again, it comes down to whether this is a "last resort" setting, or 
something you'd expect to be invoked regularly.


> I think developers of distributed systems should be aware of this - 
> and I think they usually are


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.


> If returning a 50x response with a custom message is a requirement, 
> then sure, developers can just ignore the new ini setting.
> Although, i.e. apache and nginx already allow custom error pages, and 
> I think that should just be good enough for most use-cases.


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.


> Also, please be aware that the timeout is a clean shutdownmechanism, 
> so shutdown handlers and the already mentioned RSHUTDOWN functions are 
> triggered.


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.


Regards,

-- 
Rowan Tommins
[IMSoP]