Re: AW: [PHP-DEV] Re: [RFC] Magic Method that handles unset($object)

From: 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. > >

« previous php.internals (#26924) next »