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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
