Re: Fix for bug #25543

Andi Gutmans <andi@zend.com> wrote: > Hi, > > I don't like this patch because already the gc is a very sensitive > mechanism and we're not allowed to collect too much or too little at any > given time. Your patch can easily lead to too much being collected before > previous zval's are freed which can lead to problems (this mechanism was > refined a couple of times due to such problems). > The only real solution I can see is to nuke the garbage completely. I > already have a rough idea of how to do it but it requires quite a lot of work. > BTW, I didn't quite understand the bug report 25543. It doesn't seem to be > very well written (I know it's not you :) Actually the PR number is 25547 :) Anyway, I don't think my patch is so harmful because the pointer to a zval (semantically a container of a zval instance) that has been created at certain znode construction is supposed not to be destroyed during an atomic operation, by which I mean a single opcode processing. That's why I named them zend_*_atomic(). Moriyohi > > Andi > > At 09:32 AM 10/3/2003 +0900, Moriyoshi Koizumi wrote: > >Hi, > > > >Attached is a fix for bug #25543 (Error in set_error_handler() definition), > >which is caused by disordered scheduling of the garbage collection > >(zend_clean_garbage()). > > > >With this patch I'm adding the following two inline functions, > >zend_begin_atomic() and zend_end_atomic(), to prevent GC from being > >performed at the right time. Calls to those functions are inserted > >at the beginning / end of zend_fetch_dimension_address(), > >zend_fetch_property_address(), and some other functions of the same kind. > > > >I'll commit these shortly if you don't see any problem. > > > >Regards, > > > >Moriyoshi > > > > > >-- > >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 >