Hi:
I filed a bug about SIGALRM(or SIGPROF) has chance to cause
segfault in php_error_cb. https://bugs.php.net/bug.php?id=60038
do you think this is worth fixing (in 5.4 trunk)? (as zend_signal
was introduced, and this fix will cost litte perf).
thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
Seems like a fine solution, performance loss would occur only when
error happens...
Hi:
I filed a bug about SIGALRM(or SIGPROF) has chance to cause
segfault in php_error_cb. https://bugs.php.net/bug.php?id=60038do you think this is worth fixing (in 5.4 trunk)? (as zend_signal
was introduced, and this fix will cost litte perf).thanks
--
Laruence Xinchen Hui
http://www.laruence.com/
Hi!
Seems like a fine solution, performance loss would occur only when
error happens...
Note that on 99% of real PHP code, dozens of "errors" may happen due to
multitude of notices and E_STRICTs that we have now and we have no means
to disable until the very last moment before printing them. If each of
them would cost two system calls, we may have a serious performance problem.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi:
If send signal enabled, no system will be called.
Thkans
Sent from my iPhone
在 2011-10-12，22:59，Stas Malyshev smalyshev@sugarcrm.com 写道：
Hi!
Seems like a fine solution, performance loss would occur only when
error happens...Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. If each of them would cost two system calls, we may have a serious performance problem.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
s,send,zend,
Sent from my iPhone
在 2011-10-13，8:16，Xinchen Hui laruence@gmail.com 写道：
Hi:
If send signal enabled, no system will be called.Thkans
Sent from my iPhone
在 2011-10-12，22:59，Stas Malyshev smalyshev@sugarcrm.com 写道：
Hi!
Seems like a fine solution, performance loss would occur only when
error happens...Note that on 99% of real PHP code, dozens of "errors" may happen due to multitude of notices and E_STRICTs that we have now and we have no means to disable until the very last moment before printing them. If each of them would cost two system calls, we may have a serious performance problem.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi
2011/10/13 Xinchen Hui laruence@gmail.com:
Hi:
If send signal enabled, no system will be called.Thkans
What about systems without Zend Signal Handling, like Windows?
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2011/10/13 Kalle Sommer Nielsen kalle@php.net:
Hi
2011/10/13 Xinchen Hui laruence@gmail.com:
Hi:
If send signal enabled, no system will be called.Thkans
What about systems without Zend Signal Handling, like Windows?
hmm, I have updated the patch, the fix only take affect when
ZEND_SIGNALS defined. :)
thanks
--
regards,Kalle Sommer Nielsen
kalle@php.net
--
惠新宸 laruence
Senior PHP Engineer
http://www.laruence.com
Note that on 99% of real PHP code, dozens of "errors" may happen due to
multitude of notices and E_STRICTs that we have now and we have no means
to disable until the very last moment before printing them.
Such a performance regression sounds like an appropriate "punishment" to
me for deploying bad code ;-)
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Hi!
Such a performance regression sounds like an appropriate "punishment" to
me for deploying bad code ;-)
By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because language
implementers decided to go B&D on their users? ;)
I personally hate to see all these isset($foo['bar'])?$foo['bar']:null.
I think it's bad we make people do that.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
Such a performance regression sounds like an appropriate "punishment" to
me for deploying bad code ;-)By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because language
implementers decided to go B&D on their users? ;)I personally hate to see all these isset($foo['bar'])?$foo['bar']**:null.
I think it's bad we make people do that.
and there are cases when you can't avoid triggering errors (like trying to
delete delete a while which can be deleted concurrently) so your only
option is to suppress them and handle the result based on the return value
of the statement.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Unless you are deleting thousands of files in a tight loop, the
overhead involved won't make any difference for your application.
In general your application is throwing many errors, even "benign"
E_STRICT or E_NOTICE you are already incurring a performance hit.
On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
Such a performance regression sounds like an appropriate "punishment" to
me for deploying bad code ;-)By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because language
implementers decided to go B&D on their users? ;)I personally hate to see all these isset($foo['bar'])?$foo['bar']**:null.
I think it's bad we make people do that.and there are cases when you can't avoid triggering errors (like trying to
delete delete a while which can be deleted concurrently) so your only
option is to suppress them and handle the result based on the return value
of the statement.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I know, I've just replied with an example to the "Such a performance
regression sounds like an appropriate "punishment" to me for deploying bad
code ;-)" statement.
btw:
http://www.tyrael.hu/2011/06/26/performance-of-error-handling-in-php/
http://www.tyrael.hu/2011/10/09/error-suppression-improvements-with-php-5-4/
Unless you are deleting thousands of files in a tight loop, the
overhead involved won't make any difference for your application.In general your application is throwing many errors, even "benign"
E_STRICTorE_NOTICEyou are already incurring a performance hit.On Mon, Oct 17, 2011 at 8:54 AM, Stas Malyshev <smalyshev@sugarcrm.com
wrote:Hi!
Such a performance regression sounds like an appropriate "punishment"
to
me for deploying bad code ;-)By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because language
implementers decided to go B&D on their users? ;)I personally hate to see all these
isset($foo['bar'])?$foo['bar']**:null.
I think it's bad we make people do that.and there are cases when you can't avoid triggering errors (like trying
to
delete delete a while which can be deleted concurrently) so your only
option is to suppress them and handle the result based on the return
value
of the statement.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
do you think this is worth fixing (in 5.4 trunk)? (as zend_signalwas introduced, and this fix will cost litte perf).
OK, if it doesn't cost performance then I guess it's fine to apply it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227