macro_x madness heads up

[Andreas Ericsson]

As I have promised, I have delivered. Notifications are still not
thread-safe, because I simply couldn't follow how the macros are modded
and managed both locally and globally around 4am this morning. Perhaps I
needed more red bull or, quite possibly, sleep.

There's one issue though; The new way of handling macros reverses the
memory management requirements so that memory has to be freed after it
has been used instead of kept around and re-used the next time a macro
needs updating. As such, it's quite possible I've introduced some few
memory leaks. Testing help and valgrind output snippets stating
"lala bytes definitely lost in leak record foo in
SOME_FUNCTION_WHICH_IT_IS_IMPORTANT_THAT_YOU_INCLUDE_IN_THE_MAIL_TO_ME"
would be very much welcome. The first to find two or patch one such
memory leak wins an icecream and a beer.

A bunch of checkin messages should appear on nagios-checkins soon. For
those of you who do not follow that tremendously boring list, here's the
gist of the two patches I wrote to make at least performance data
handling work from multiple threads (chronologically ordered):

Author: Andreas Ericsson <ae at op5.se>
Date:   Thu Oct 28 05:01:13 2010 +0200

    Make performance-data handling and checks thread safe
    
    It's a bit early to tell, but at least we've gotten rid of
    the horrible global macro management now, in favour of a macro
    struct that gets passed around. In truth though, the whole
    macro machinery needs a rewrite in order to make good sense.
    
    Getting all the data before we even know we need it doesn't
    even begin to make sense, but with this patch we can at least
    start using concurrent performance-data updates while checks
    are being started at the same time, and since notifications
    is currently the only thing (I hope) that isn't overly scratched
    by this patch, Nagios won't have any issues sending those out
    while other code looks to performance-data and firing up
    checks.
    
    As a fall-back for eventbroker modules and whatnot that
    references the global macro_x variable, we retain it but make
    it point to the global_macros.x. This requires that macros
    have been initialized, but any code that referenced macro_x
    before initialization was doomed to "undefined behaviour"
    earlier anyway, so the fact that they will now for certain
    segfault on such actions is probably an improvement.
    
    For backwards compatibility with existing modules, we let
    process_macros() and get_raw_command_line() exist with their
    previous signatures and act as wrappers for the reentrant
    versions providing the same functionality, passing a global
    'nagios_macros *' struct as first argument. The reentrant
    versions are, as per best practice, named "process_macros_r()"
    and "get_raw_command_line_r()", respectively. I only checked
    NDOUtils and DNX for compatibility, so other projects may
    suffer.
    
    Gargantuan patch, I know. The macro machinery was far more
    central to the Nagios core than I first imagined.
    
    Signed-off-by: Andreas Ericsson <ae at op5.se>

 27 files changed, 979 insertions(+), 960 deletions(-)

Author: Andreas Ericsson <ae at op5.se>
Date:   Thu Oct 28 12:14:07 2010 +0200

    xpddefault: Use a mutex when writing to and updating perfdata files
    
    Running commands doesn't need this, but a combination of threads
    writing, opening and closing the xpddefault_*_perfdata_fp streams
    is a recipe for disaster. At least the locks are very short-lived,
    and should never even block unless threads from modules also try
    to update the performance data files.
    
    Signed-off-by: Andreas Ericsson <ae at op5.se>

 1 files changed, 28 insertions(+), 16 deletions(-)

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev