On Thu, Mar 27, 2008 at 08:07:49AM -0700, Witham, Timothy D wrote: > > If we remove the conditional the lock should silently fail and so we > would get the same result. This would make the code a bit simpler and > I'm OK with that.
Committed revision 1138. > But it looks like the only way it can fail is if > it hasn't been initialized. And we know that it does get initialized so > it's probably OK to just make the [un]lock calls with no conditionals or > error checking, like the rest of the code does. there seem to be other problems with multiple initialization paths for this lock and some inconsistent handling of it as well, so some more cleanup might be required around it in the long run which will result in a more intrusive patch. the use of the lock as added for this patch is correct, but since the rest of the code around its usage might not be, the end result (which just happens to work now somehow) might be unstable as well, and so this will require more testing or a more comprehensive fix to go to stable. -1 Carlo ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
