Malte Helmert added the comment: If I remove the "#define 60" line in an unmodified posixmodule.c from trunk, I get the following compiler error:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function posix_times: ./Modules/posixmodule.c:5964: error: HZ undeclared (first use in this function) So yes, HZ isn't available there. It sure is defined *somewhere* (grep shows a definition in /usr/include/asm-x86_64/param.h), but it isn't anywhere Python would pick it up. And I don't really see why it should when the man pages all argue that using HZ for times is for "older system" (this is a man page from 2002, no less!). Can you measure a performance difference between your patch and the old buggy behaviour? I couldn't, on any machine, and I'd be very surprised if it existed. There is no significant difference between dividing by a constant and diving by a static module variable, and, as Antoine rightly suggests, any such difference would be completely lost in the noise considering the hefty cost of the other operations. Regarding your two issues: 1. Yes, the sysconf value should take precedence over HZ, since this is what "man 2 times" says you should use. 2. Personally, I'd be just as fine with the original patch that doesn't have the code complexity of the value caching, but I'm fine with anything that fixes the bug. Keeping the old behaviour where possible "for old time's sake" seems a bad idea -- there were at least two broken platforms (Mac OS and Xeon), and there may be others. Using the documented behaviour (sysconf) where available is a much better solution; honestly, sticking to using HZ as a default without support for that from any documentation has a cargo-cult programming smell to me. I don't know if there are platforms that have times, but neither sysconf nor HZ. That sounds very strange to me, but of course I can't rule it out. But if there are, it is likely that os.times was broken before on these platforms -- it was broken on two platforms that I wouldn't consider minor. In that case, it will still be broken, but at least now we have a unit tests that detects this. _____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1040026> _____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
