Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28876
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.132.248 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=F6FNUN4oNU9Z5G76KrkUrtJ46TqHimQdx5a9d1CUCrHS+yR6E667aKP3GsfK0Xe6QYvdrm8Lb/q8Y2sNSYwNRvC9k2pD35RKxeD/4F9YS2d7T4yehX6F8KKWXudd25gMHnjC/21eXnarCtEhQ5EPW3OMJx88KZ9WIV2xtzcQdrI=
Message-ID: <7cea347c0704170116j3ba50dbbrd7cc36780ead7164@mail.gmail.com>
Date: Tue, 17 Apr 2007 10:16:06 +0200
To: internals@lists.php.net
In-Reply-To: <4623BDF4.8010005@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <7cea347c0704160319x619b26d0s7716e35493e122c4@mail.gmail.com>
	 <4623BDF4.8010005@zend.com>
Subject: Re: [PHP-DEV] Trapping "memory exhausted" error
From: david.sklar@gmail.com ("David Sklar")

On 4/16/07, Stanislav Malyshev <stas@zend.com> wrote:
> > - in addition to a memory_limit configuration directive, there could
> > be a "memory_limit_grace" configuration directive. This gets stored in
> > the struct _zend_mm_heap, along with the limit.
>
> That could be a problem because it's very hard to know exact memory
> requirements for PHP code for most people not intimately knowing the
> engine internals, and also recovering from failed allocation usually is
> not simple since management structures could be in half-done state. So
> writing useful handler for such an error would be rather hard to do.
>
> Having said that, what exactly would you plan to do in this error handler?

In my current situation, bail out, but gracefully -- perhaps just send
a 302 to an error page and exit; maybe instead throw away the output
buffer and then directly output some friendly error text.

The idea would be not to recover from the failure and proceed with a
separate script execution path that requires a lot less memory, but to
have things fail more gracefully than just splatting a Fatal Error. So
being able to calculate with great accuracy the memory requirements of
particular bits of PHP code shouldn't be a prerequisite to making this
sort of thing useful.

That said, given the history of just about every other feature in PHP,
it wouldn't be surprising for people to attempt to use this feature to
do all sorts of crazy things after the soft memory limit has been
reached, and in that case they'd want to be able to calculate the
appropriate size of their grace period, but if they're going to go to
such contortions, then that's what they're stuck with.

David


Richard Lynch <ceo@l-i-e.com> wrote:
> You might also come at it from the other direction and detect/notify
> at some number smaller than the current hard limit, configurable in
> php.ini...
>
> This might play better with anything relying on the current behaviour

This is interesting and might actually take care of a lot of cases. I
don't know enough about the existing memory manager to know if it
would handle the case where a single new allocation would blow through
both the (lower) soft limit and the hard limit at the same time.

David