Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28914
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.132.251 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=FqAEqjr112WnLRQ/sryW+GHZSpIGrjy+vYrRxHrzEBcJlDexX0eGwEaI1SY6D6MocorvoeLaFyF36AIg10Yz0Me6C2vuWzeYA2t8bAJ8JKDgbLWLGjCOpceWX5I7g6hTg/J42XBOTpt6JGcUaBIdzaqVJM1LAwDfDldf+CB+h3Q=
Message-ID: <7cea347c0704180037o7485422ar8dc816a9c57fe352@mail.gmail.com>
Date: Wed, 18 Apr 2007 09:37:55 +0200
To: internals@lists.php.net
In-Reply-To: <3293.209.254.223.2.1176846979.squirrel@www.l-i-e.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>
	 <7cea347c0704170116j3ba50dbbrd7cc36780ead7164@mail.gmail.com>
	 <3293.209.254.223.2.1176846979.squirrel@www.l-i-e.com>
Subject: Re: [PHP-DEV] Trapping "memory exhausted" error
From: david.sklar@gmail.com ("David Sklar")

On 4/17/07, Richard Lynch <ceo@l-i-e.com> wrote:
> On Tue, April 17, 2007 3:16 am, David Sklar wrote:
> > 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.
>
> If an allocation blows through the hard limit, it should behave
> exactly as it does now, for BC, imho.
>
> If you let the developer decide on a "soft limit" or a percentage of
> the "hard limit" where some callback function happens, it's on their
> heads if they do something silly that rips right past their selected
> soft/hard limits.

Well, the BC case could be handled by doing what you suggest if the
"grace limit" config option isn't defined.

I think it's important, in the case that the grace limit is set up, to
trigger its behavior even if a single allocation blows away both so
that the recovery can be graceful. For example, if you're retrieving a
feed to parse or the contents of a file and that feed or file is
unexpectedly large so it blows through both memory limits.

David