Re: AW: [PHP-DEV] Re: [RFC] Magic Method that handles unset($object)
| From: | Arnold Daniels | Date: | Tue, 12 Dec 2006 20:10:24 +0000 |
| Subject: | Re: AW: [PHP-DEV] Re: [RFC] Magic Method that handles unset($object) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-26924@lists.php.net to get a copy of this message | ||
Hi,
Yes something like that sounds good. Having to gc_cleanup() at places
within the code would be kind of messy, but perhaps calling something
like enable_mem_cleanup() at the beginning of the script could be a good
solution. Or perhaps just stealing ... ehhh borowing ... the
implementation from Python.
I believe that this is a problem where everybody who wants to use PHP
for more that small request/responce webscripts, is running into. The
problem and solution are to complicated for me to try to write a patch,
but I hope someone developing on the Zend Core will pick this subject up
and give it priority. (This should be the right list to find some
volunteer :)
Best regards,
Arnold
Matthias Pigulla wrote:
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Ants Aasma [mailto:ants.aasma@gmail.com]
>>
>
>
>> That would indeed be too slow. The standard way to handle
>> this, is to only check visibility periodically. That is how
>> Java, .NET, Python and countless others do that. Check
>> http://www.hpl.hp.com/personal/Hans_Boehm/gc/ for a sample
>> of
>> how an implementation might look like.
>>
>
> The whole issue comes up regularly on various lists, e. g. Propel or Phing suffer from it. Also
> see http://bugs.php.net/bug.php?id=33595. Working around this in
> userland may be possible but is at least painful and messy.
>
> If the only problem is that detection is slow, wouldn't it be possible to add a
> gc_cleanup() function that performs the scan? Those who use PHP in a request/response environment
> need not care (everything is freed at the end of the request). Those who don't and hit the
> problem regularly will find a good place to make this call and certainly won't complain about
> the delay.
>
> mp.
>
>