Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112524
To: internals@lists.php.net
References: <CAH5C8xW981Fn91HsHmZfbLseXwSyOtM1X5u1zsAL4ofXhka=nw@mail.gmail.com>
 <CAEPJdumFUe53ccUwCib_xJFuMQAu1sYXg_3Me4umnSrxbPUS3w@mail.gmail.com>
 <CAH5C8xUAg3V8ELDJgDbj7qKhiNo3E3MfB4JnyWJxMe=AmBrbsw@mail.gmail.com>
Message-ID: <9b36af8a-270f-2796-194e-b50296522407@gmail.com>
Date: Wed, 16 Dec 2020 09:57:53 +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: <CAH5C8xUAg3V8ELDJgDbj7qKhiNo3E3MfB4JnyWJxMe=AmBrbsw@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 15/12/2020 23:12, Máté Kocsis wrote:
> I've just collected a few examples when my proposal would be useful:
> https://gist.github.com/kocsismate/dbcc4ba81b27cfb2e25b949723bb7c79
>
> [...]
>
> Do the above examples and this reasoning make sense to you? Also, I'll
> improve the wording I used when describing the consequences.


The part I'm curious about is not so much when the setting would have an 
effect, as when it would be the desired solution.

Your point about the server not being able to serve any more connections 
is reasonable, and I can see this being a useful last resort mechanism 
to keep the server responding. I'd be likely to treat it similarly to 
the Linux OOM killer: if it was ever actually invoked, I would be 
investigating how to fix my application.

The wording in your e-mails and RFC suggests you see it as something 
you'd use instead of application-level solutions, rather than as well as 
them, and that's what I'm trying to picture the use case for.


One scenario I can think of would look a bit like this:

foreach ( $ordersToProcess as $orderDetails ) {
     $result = send_order_to_remote_system($orderDetails);
     save_confirmation_to_db($orderDetails->customerOrderRef, 
$result->supplierOrderRef);
}

If the remote system responded very slowly, that loop might take many 
times the expected duration. If we simply kill the process when a fixed 
wall time has elapsed, we're very likely to create an order on the 
remote system, but exit without saving its reference. It is however easy 
to see where in that loop we could safely call a routine like 
throw_exception_if_time_limit_reached().

If rather than placing orders, the loop was just gathering search 
results, killing the process would be less dangerous, but cleanly 
exiting would still be preferable, because we could return a warning and 
partial results, rather than a 500 error.


Other scenarios I can think of have similar problems:

* If the database locks up inside a transaction, killing the process 
probably won't roll that transaction back cleanly
* If the process was working through a large import of data, it may have 
written a bunch of temporary data to disk or holding tables which won't 
be cleaned up

In other words, I can only think of cases where "the cure would be worse 
than the disease".


Regards,

-- 
Rowan Tommins
[IMSoP]