Ah, excellent, thanks. I'll take a look. This looks like what
http://ez.no/doc/components/view/latest/(file)/Execution/ezcExecution.html
does (Derick mentions this in the comments at
http://php100.wordpress.com/2007/04/16/graceful-recovery/)
Yes, that's basically where I've got the idea. Looks l
On 4/17/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> 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.
I think you can do it with shutdow
On 4/17/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Tue, April 17, 2007 3:16 am, David Sklar wrote:
> Richard Lynch <[EMAIL PROTECTED]> 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.
On Tue, April 17, 2007 3:16 am, David Sklar wrote:
> Richard Lynch <[EMAIL PROTECTED]> 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 relyi
On Tue, April 17, 2007 3:18 am, David Sklar wrote:
> On 4/17/07, Peter Hodge <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> A soft memory limit could be very useful; it doesn't necessarily
>> need to throw
>> an error, but it would provide an opportunity to free some memory
>> and prevent
>> the script
I have code at Facebook that currently does something similar by
catching fatal errors but there's a lot of gotcha's obviously that
need to be handled properly when the engine is in this state. When
possible we enable the printing of backtraces and other debug
information, however you ru
2007. 04. 17, kedd keltezéssel 10.18-kor David Sklar ezt írta:
> My intention with the grace limit was to provide a graceful way of
> failing, not to continue processing in a reduced state -- as Stanislav
> said above, it could be difficult to do a lot after the allocation has
> failed.
What if t
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.
I think you can do it with shutdown handler, shouldn't it work? I.e. you
can do it this way:
1.
On 4/17/07, Peter Hodge <[EMAIL PROTECTED]> wrote:
Hello,
A soft memory limit could be very useful; it doesn't necessarily need to throw
an error, but it would provide an opportunity to free some memory and prevent
the script from crashing. Perhaps something like:
// function to call when me
On 4/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> 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 ha
Hello,
A soft memory limit could be very useful; it doesn't necessarily need to throw
an error, but it would provide an opportunity to free some memory and prevent
the script from crashing. Perhaps something like:
// function to call when memory is running out
register_memory_limit_handler('
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.
On Mon, April 16, 2007 5:19 am, David Sklar wrote:
> I am interested in being
- 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 peop
13 matches
Mail list logo
