Well, the general idea is that any call that can cause recursion or iteration should at least do check_threads *sometimes*. However, beware that it is really easy to cause loooong delays (several seconds) between calls to check_threads_etc() if you use fast_check_threads instead. If I remember correctly, I first replaced all check_threads_etc() with fast_check_threads_etc(), but that caused problems for some applications...
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2002-09-10 02:02: Subject: Frequent context switches
Compared to a context switch it ought to be negligible. So an alternative way could perhaps be to measure the divisor at startup, and also have a counter over active threads so the function doesn't do anything if there's only one thread running. (It could perhaps even be removed from evaluator_callbacks altogether then.)
Btw, is gethrtime always cheap? Wouldn't it be wise to put that too behind the div_ check?
I've investigated the reason for the frequent calls a bit more now, and I think there are some suspect check_threads_etc() in apply_low.h. E.g. the following program generates 4 million calls per second to check_threads on my system:
int gronk() {return 17;} void work() { while (1) gronk(); }
int main() { for (int i = 0; i < 5; i++) Thread.thread_create (work); sleep (10); }
The reason for the many calls is the pike function call in the loop. Every pike function call and most lfun calls causes a call to check_threads, while many other call variants do not. Is there a reason for this? I'm considering replacing all the check_threads_etc() calls in apply_low.h with a single fast_check_threads_etc(6) at the top.
/ Martin Stjernholm, Roxen IS