[PATCH] move thread safe macro function prototypes with suffix _r and restore old compatible prototypes again

Michael Friedrich michael.friedrich at univie.ac.at
Wed Feb 9 17:54:46 CET 2011


-------- Original Message  --------
Subject: Re: [Nagios-devel] [PATCH] move thread safe macro function 
prototypes with suffix _r and restore old compatible prototypes again
From: Andreas Ericsson <ae at op5.se>
To: Nagios Developers List <nagios-devel at lists.sourceforge.net>
Date: 2011-02-09 17:17
> On 02/09/2011 04:35 PM, Michael Friedrich wrote:
>> Hi there,
>>
>> I had a little chat with Sven Nierlein yesterday about the compatibility of mod_gearman to current Nagios and Icinga versions. Both HEADs contain the recent changes by Andreas regarding the thread safety for macros, while the released versions don't have that.
>> mod_gearman makes use of the NEB_CALLBACK_OVERRIDE/CANCEL and in order to run a check on their own, some logic on doing a check is copied from base/checks.c including the clear_volatile_macros() function.
>>
>> Since this is now changed into the thread-safe implementation requiring nagios_macros* mac as argument, mod_gearman will produce a segfault. Naturally, a workaround on the module would resolve that when Nagios gets released, but possibly other NEB modules (or just older versions of mod_gearman or mklivestatus e.g. in packages) are using that functionality too, and won't work anymore.
>> As far as I have checked against the source code, Merlin does not make use of those, neither do *DOUtils. On MK Livestatus I do remember some flaws but on the latest innovation release (not stable), those seem to be resolved. But as on previous changes, this might be a hidden source which breaks everything.
>>
>>
>> In order to keep that clean, straight forward and compatible with older releases, I'd like to suggest the attached patch against the current Nagios git HEAD (from git.op5.org) which does basically the following:
>>
>> * rename *_macro() into *_macro_r()
>> * add the non thread safe void argument function *_macro() again, calling *_macro_r() with&global_macros argument
>> * put both versions into the macro.h
>> * replace all internal core functionality to use the thread safe version
>>
> This is already done for the functions I found that are used by
> modules, so it's obviously a sensible approach.

Ah yes, within all that code I forgot to mention that - process_command 
and get_raw_command_line are already being treated with their given _r 
suffix.
Meanwhile - several other changes on macros in base/* are also there, 
but right on i did not find any modules using those down below core 
functionality so it's best to keep them like they are right now. 
Although I do think that thread safe functions should be marked with _r 
suffix all over the code - it makes sense for some tech docs and future 
development.

> Thanks. I'll apply and push this before the weekend.

Thanks!

Kind regards,
Michael

-- 
DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email: 	michael.friedrich at univie.ac.at
phone: 	+43 1 4277 14359
fax: 	+43 1 4277 14338
web:	http://www.univie.ac.at/zid
	http://www.aco.net

Icinga Core&  IDOUtils Developer
http://www.icinga.org


------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb




More information about the Developers mailing list