pcp
[Top] [All Lists]

libpcp pdubuf fix (was Re: pcp updates: libpcp, pcp-uptime, docs, qa)

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Subject: libpcp pdubuf fix (was Re: pcp updates: libpcp, pcp-uptime, docs, qa)
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Wed, 16 Sep 2015 02:42:18 -0400 (EDT)
Cc: pcp <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0meghz2v7u.fsf@xxxxxxxx>
References: <1653198047.32442774.1442300655332.JavaMail.zimbra@xxxxxxxxxx> <484231901.32444837.1442300926325.JavaMail.zimbra@xxxxxxxxxx> <y0meghz2v7u.fsf@xxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: +GnP0FcCE2/M4GLAAwNfwF5ahLBT0w==
Thread-topic: libpcp pdubuf fix (was Re: pcp updates: libpcp, pcp-uptime, docs, qa)

----- Original Message -----
> 
> > Nathan Scott (5):
> >       libpcp: temporarily revert pdubuf tsearch-based optimisation
> 
> It turns out this is the right thing to do.

Never any doubt - stability over performance.

> [...]
> So a the pointer 0x1005da30 was deemed to fall into the interval of
> that first pdubuf 0x10050d8a0...0x10050da2f[400](10), when actually it
> is actually outside (by one byte).  Things go downhill very gradually
> from this point.  I'm testing a fix and qa, should be ready tomorrow.
> 

Great work!

Given the nature of where this change is in libpcp - i.e. affecting every
PMAPI collector and monitor tool ever - and with the reverted optimisation
affecting only pmwebd with multiple concurrent threads AIUI), I am leaning
toward going with the known-stable original pdubuf code for this release.

Let's tee this fix up with the other pending pcp-3.10.8 commits, and get
it merged in the first week to maximise soak time.  Thanks!

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>