Patch for 2.12 utilize sched_yield instead of sleep in event_loop attached for comments

[eponymous alias]

It seems unlikely that you would want to
#include <sched.h>
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 <smorrey at ldschurch.org> wrote:

> From: Steven D. Morrey <smorrey at ldschurch.org>
> Subject: [Nagios-devel] Patch for 2.12 utilize sched_yield instead of sleep in event_loop attached for comments
> To: "nagios-devel at lists.sourceforge.net" <nagios-devel at lists.sourceforge.net>
> 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



      

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf