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 able to trap the (currently) fatal error that > results when memory usage exceeds the defined memory limit. > > I was thinking it could work as follows: > > - 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. > > - Also added to struct _zend_mm_heap is a "initial limit reached" flag > > - When zend_mm_safe_error() in Zend/zend_alloc.c is invoked under the > current conditions (memory_limit exceeded), it sets the "initial limit > reached" flag, adjusts the heap limit to the "memory_limit_grace" > value and throws some non-fatal error (or an exception if it is > feasible from here.) > > - When zend_mm_safe_error() is invoked and the "initial limit reached" > flag is already set, it throws the fatal error exactly as it does now. > > This "grace period" would provide a way to gracefully exit when a > memory limit is reached, but also has the hard limit still enforced so > that code which is supposed to be gracefully exiting doesn't chew up > too much additional memory. > > Is it feasible to adjust the heap limit and throw a non-fatal error > from within zend_mm_safe_error()? > > David > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
