Re: [RFC] Zend Signal Handling

Hi, On Wednesday 13 August 2008 10:09:43 Dmitry Stogov wrote: > Hi Lucas, > > I took a look into patch and I still don't like it. > I may miss some things and make mistakes so correct me if I'm wrong. > > 1) It makes some slowdown for all SAPIs except Apache1, because it adds > additional block/unblock code (mainly in zend_alloc.c) The added block/unblocks are really needed, for instance in _zend_mm_alloc_int when a small free block is found, it has to maintain the cache, etc and an interruption here can cause some unwanted behaviors. > > 3) The patch cannot solve all issues caused by SIGALARM handling, > because PHP has thousand places which may stay data in inconsistent > state (or data allocated in permanent heap). Wrapping all of them with > block/unblock is not a decision. > > small issues: > > 4) block/unblock code in estrndup() and some other functions is useless. > It should be removed. I added that in estrndup() during testing as an interrupt in this function caused "String is non-zero terminated" warnings. > > 5) TSRM_FETCH() in zend_hash and zend_alloc functions will slowdown > Windows ZTS build even if it doesn't use signals. It may be changed to > some other macro that will do TSRM_FETCH only if signals are enabled. This can be done. For zend_alloc, as _emalloc already does TSRMLS_FETCH(), it is possible to pass the tsrm_ls directly as argument to _zend_mm_alloc_int(). _efree, _erealloc, etc do TSRMLS_FETCH() too. There is a ~5% slowdown on bench.php with ZTS builds with the patch applied. And ~3% when passing tsrm_ls to _zend_mm_alloc_int/free/realloc(). Passing the tsrm_ls to hash functions may avoid this slowdown but this requires huge changes. > > May be if we really like safe SIGALARM handling we may use Windows > decision for UNIX too. I mean setup of EG(timed_out) flag in signal > handler and checking it in execute loop. As an optimization we can check > it not on each instruction but only on enter in function and JMP* > opcodes (loops). Anyway, this solution may cause comparable slowdown. It may be a good solution too. Just removing #ifdefs around timed_out (so, without any optimization) gives a 1 to 2% slowdown. Regards, Arnaud