It seems unlikely that you would want to
#include
unconditionally and then only conditionally
invoke sched_yield().
If you are going to conditionally invoke
sched_yield(), then it ought to be done for
the __sun__ platform as well. And for that
matter, the appropriate preprocessor symbols
for non-GCC compilers ought to be checked
as well. Probably better overall is to
depend instead on some global flag of your
own which is not platform-specific, much like
the ./configure --enable-event-broker option
generates the USE_EVENT_BROKER flag.
Those are low-level critiques. But overall,
I'd be happier if sigtimedwait() were used
instead of sched_yield(). There's little
reason to keep cycling back and forth
between kernel and user space, wasting at
least some amount of system resources,
instead of just waiting exactly long enough.
You would need to block SIGCHLD in all threads
(easy -- call sigblock() at startup), put in
place a trivial SIGCHLD handler (just returns)
in order to get a non-default disposition of
this signal so the waiting thread can receive
the signal (use sigaction() and remember to
set the SA_RESTART flag), and call
sigtimedwait() instead of sched_yield().
This would keep the waiting thread completely
off the CPU(s) until there is really some
work to do, or until the thread gets nervous
about the wait and times out, at which point
it could regain control and kill some errant
child process which is believed to be taking
too long to execute. (That last could be a
future enhancement.)
--- On Tue, 4/28/09, Steven D. Morrey wrote:
> From: Steven D. Morrey
> Subject: [Nagios-devel] Patch for 2.12 utilize sched_yield instead of sleep in event_loop attached for comments
> To: "[email protected]"
> Date: Tuesday, April 28, 2009, 11:40 AM
> I've attached a patch and am seeking
> comments.
> It won't cure cancer but if you have some non-parallel
> checks it may reduce your overall latency
>
> Sincerely,
> Steve
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]