(Resurrecting a very old thread. Sorry about the thread necromancy.) On 8 September 2011 05:20, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 09/07/2011 02:12 PM, Stas Malyshev wrote: >> But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up >> itimer implementation at least up to kernel 10.8.0, Mac OS X 10.6.8. >> Didn't try it on Lion, maybe the have updated/fixed it. > > Right, so we need to decide what to do about that. Timing out a tight > loop with absolutely nothing inside isn't a typical user scenario, so > for this particular case we could probably just make the for loop do > something trivial. But we should also note this somewhere and maybe have > a Darwin-only XFAIL test case.
I've been trying to run down tests/func/005a.phpt failing this morning, and obviously this is the cause. I don't have a Lion machine to hand to test this there, but it does look like ITIMER_PROF is completely broken on OS X 10.6.7 and 10.6.8. Options: - Skip tests/func/005a.phpt on Darwin and add an XFAIL version for Darwin, as Rasmus suggested above. Probably the only sensible solution for 5.4, since it doesn't involve a change to the runtime proper. - Extend the #ifdef __CYGWIN__ in zend_set_timeout() and zend_signal_register() to include Darwin, and consequently set ITIMER_REAL and listen to SIGALRM on Darwin, accepting the change in max_execution_time semantics (real time versus process virtual time) but at least having something that works. Might be worth trying on trunk and in PHP 5.5 (when that comes) to see if it feels better. For me at least, tests/func/005a.phpt is the last failing test on PHP_5_4 on my OS X machine, so it would be nice to get this cleared up pre-5.4.0 to help get cleaner test suite results. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
