Something like the variables produced by perl's my() operator so that a variable is lexically scoped along with block-level scoping could help earlier detection of when it's possible to release a variable. This wouldn't solve leaks, but it might help prevent some
On 10/28/05, Andi Gutmans <[EMAIL PROTECTED]> wrote: > What do you mean? > > At 06:50 PM 10/28/2005, Sebastian wrote: > >Lexical variables would be nice. > > > >On 10/28/05, Andi Gutmans <[EMAIL PROTECTED]> wrote: > > > Hi Cristiano, > > > > > > Alex sent a patch to the list a while ago which forces the memory > > > allocator to return memory to the system. However, in your case, I > > > think you might be just having PHP variables "leaking". Can you try > > > and identify where this info is sitting and try and unset it? It's > > > important to dig deeper and/or reproduce in order to understand. > > > > > > > > > Andi > > > > > > At 12:21 PM 10/28/2005, Cristiano Duarte wrote: > > > >Is there any way to force a PHP CLI application to free the memory it > > > >took > > > >from the system ? I mean, is there any PHP userland or PHP internal > > > >functional call that could *really* free 'the memory allocated by a > > > >variable' or 'the memory allocated but currently not used and waiting for > > > >the script end to be freed' ? > > > > > > > >Regards, > > > > > > > >Cristiano Duarte > > > > > > > >-- > > > >PHP Internals - PHP Runtime Development Mailing List > > > >To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > >-- > > > > > > > >------------- > >[EMAIL PROTECTED] > > -- ------------- [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
