ifferent methods of locking this up, and have come to the conclusion that =
the only maintainable solution is to do pretty much what Andreas says.
I didn't want to do it this way right off because it requires a substantial=
refactor of key areas of code, but in the long run it will be worth it, es=
pecially if later profiling reveals that other threads could be useful.
Unfortunately Nagios uses lots of globals, however the macro stuff is all I=
'm concerned with for now.
A simple grep of the sources (Nagios 2.7) shows 617 references to the word =
macro.
Many of these are close together and are good candidates for extraction int=
o their own functions anyways.
For those that aren't, most of the stuff is direct access to the object, wh=
ich could be fixed by disallowing access to the underlaying object directly=
and instead create a series of get/set wrapper functions with built in mut=
exes, effectively an API (although wrapper is what I'd be tempted to call i=
t).
Anyways I'll get to work on this and as soon as I can, I'll try to do the s=
ame in the 3.x branch so the majority of folks can have a go at it seeing h=
ow it works for them.
Sincerely,
Steve
________________________________________
From: Steven D. Morrey [[email protected]]
Sent: Thursday, August 20, 2009 9:15 AM
To: Nagios Developers List
Subject: Re: [Nagios-devel] Multithreading Segfaults
Right but that moves out of the area of a simple patch and into something s=
ignificantly more complex.
I'm trying to avoid doing that, because we're still dealing with 2.7 here, =
but I agree with you, it's the proper way of doing it.
If this works, when my employer moves to the 3x branch, I'll look at rework=
ing it that way.
Sincerely,
Steve
________________________________________
From: Andreas Ericsson [[email protected]]
Sent: Thursday, August 20, 2009 3:00 AM
To: Nagios Developers List
Subject: Re: [Nagios-devel] Multithreading Segfaults
Steven D. Morrey wrote:
> I think I've got it mostly worked out now. Turns out lots of
> functions call eachother, thereby producing a race. The trick seems
> to be to ONLY lock the sections of code dealing directly with macro_x
> and not just the entire function dealing with macro_x itself. I'm
> going to give it 12hrs of run time and then I'll get a patch up for
> testing.
>
The "right" way of doing that is to lock down the global arrays in a
single file and then publish a thread-safe API to manipulate it. The
thread-safeness can be taken care of by the simple expedient of adding
locks to start with, and later one can modify the functions so that
hostnames etc are added in a function-local stack-allocated array
instead, which could potentially increase performance quite a lot
(and also reduce memory fragmentation quite a bit).
--
Andreas Ericsson [email protected]
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.
---------------------------------------------------------------------------=
---
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus =
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Nagios-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/lis ... gios-devel
NOTICE: This email message is for the sole use of the intended recipient(s=
) and may contain confidential and privileged information. Any unauthorized=
review, use, disclosure or distribution is prohibited. If you are not the =
intended recipient, please contact the sender by reply email and destroy al=
l copies of the original message.
--------------------------------------------------------
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: ndreas Ericsson [[email protected]