On Thu, May 24, 2012 at 5:37 PM, Tobias Burnus <bur...@net-b.de> wrote: > On 05/23/2012 10:43 PM, Janne Blomqvist wrote: >> >> the attached patch allows the use of clock_gettime() with >> CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID if the target >> doesn't have getrusage() or times(). > > > It's not completely clear to me whether CLOCK_PROCESS_CPUTIME_ID or even > CLOCK_THREAD_CPUTIME_ID are always better than "clock()".
AFAICS, CLOCK_PROCESS_CPUTIME_ID should roughly measure the same thing as clock(), except with higher resolution and no wraparound issues. So yes, I think it's always better. Better than CLOCK_THREAD_CPUTIME_ID, maybe not, since that measures a slightly different thing. But, I'm counting on vxworks being the only target without getrusage(), times(), or CLOCK_PROCESS_CPUTIME_ID, and a clock() which always returns error. Hence I put the clock_gettime block ahead of the clock() block. If a target turns up where this logic breaks down we can revisit it then IMHO, rather than worrying prematurely about it. > In case of VxWorks > the answer is probably yes as its clock() returns -1 (no per-process clock > exists), though unless there is a thread, the patch won't change the result > of -1. My understanding of the docs was that it would return the CPU usage of the calling thread; with a process always having >= 1 thread(s). So it "should" work, although for a multithreaded program the result would be different compared to the other methods in gf_cputime which all measure per-process CPU usage. > I was wondering whether "call cpu_time()" alias clock_gettime with > CLOCK_MONOTONIC would be better. (Returns time since startup in case of > VxWorks, but could be also something else like time since the epoch.) Hmm, for system_clock our first choice is clock_gettime with CLOCK_MONOTONIC (see gf_gettime_mono in system_clock.c) yes, but I don't see how that would be appropriate for cpu_time. > OK for the trunk. Thanks, committed as r187846. -- Janne Blomqvist
