The use of #elif rather than #else in this code
+ #if CPU_TIME_IS_THREAD_LOCAL == YES + OBJ2THREAD(Pike_interpreter.thread_id)->auto_gc_time += last_gc_time; + #elif CPU_TIME_IS_THREAD_LOCAL == NO + auto_gc_time += last_gc_time; + #endif
seems to suggest that setting CPU_TIME_IS_THREAD_LOCAL to something other than `YES' or `NO' is valid, and results in no gc time accounting at all. Is that correct? In that case I suspect grubba's fix for the no-treads case is incomplete. If not, why are there two tests here?
CPU_TIME_IS_THREAD_LOCAL has three valid states: YES, NO and UNKNOWN (cf configure.in line ~5828).
In the no threads case, the measured cpu time can be regarded as process global.
/ Henrik Grubbström (Lysator)
Previous text:
2003-02-10 13:06: Subject: CPU_TIME_IS_THREAD_LOCAL
The use of #elif rather than #else in this code
- #if CPU_TIME_IS_THREAD_LOCAL == YES
OBJ2THREAD(Pike_interpreter.thread_id)->auto_gc_time += last_gc_time;- #elif CPU_TIME_IS_THREAD_LOCAL == NO
auto_gc_time += last_gc_time;- #endif
seems to suggest that setting CPU_TIME_IS_THREAD_LOCAL to something other than `YES' or `NO' is valid, and results in no gc time accounting at all. Is that correct? In that case I suspect grubba's fix for the no-treads case is incomplete. If not, why are there two tests here?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Is the UNKNOWN case meaningful? Shouldn't there be process global accounting in this case too? The global variable isn't even declared unless CPU_TIME_IS_THREAD_LOCAL has the value `NO'.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-10 13:11: Subject: CPU_TIME_IS_THREAD_LOCAL
CPU_TIME_IS_THREAD_LOCAL has three valid states: YES, NO and UNKNOWN (cf configure.in line ~5828).
In the no threads case, the measured cpu time can be regarded as process global.
/ Henrik Grubbström (Lysator)
If it defaults to NO in the unknown case and the accounting actually is thread local then there's a big risk that gethrvtime starts returning negative values.
The UNKNOWN case should never happen if the configure test works, but I wasn't sure enough of that. I made a fallback instead of an AC_MSG_ERROR since I thought it would be annoying if the builds fail utterly because of it.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-10 13:15: Subject: CPU_TIME_IS_THREAD_LOCAL
Is the UNKNOWN case meaningful? Shouldn't there be process global accounting in this case too? The global variable isn't even declared unless CPU_TIME_IS_THREAD_LOCAL has the value `NO'.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Then the correct thing to do in the non-threads case is to define it as NO, since there will only be one thread and it doesn't matter if accounting is per thread or not, right? Seems more sane than kludging in a lot of defined(PIKE_THREADS) all over the place.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-10 18:42: Subject: CPU_TIME_IS_THREAD_LOCAL
If it defaults to NO in the unknown case and the accounting actually is thread local then there's a big risk that gethrvtime starts returning negative values.
The UNKNOWN case should never happen if the configure test works, but I wasn't sure enough of that. I made a fallback instead of an AC_MSG_ERROR since I thought it would be annoying if the builds fail utterly because of it.
/ Martin Stjernholm, Roxen IS
Yes, it is NO (or actually PIKE_NO now) in the nonthreaded case. The kludges with PIKE_THREADS didn't address the real issue and are removed now.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-10 18:47: Subject: CPU_TIME_IS_THREAD_LOCAL
Then the correct thing to do in the non-threads case is to define it as NO, since there will only be one thread and it doesn't matter if accounting is per thread or not, right? Seems more sane than kludging in a lot of defined(PIKE_THREADS) all over the place.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum