pcp
[Top] [All Lists]

Re: [pcp] Another thread-safe issue

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] Another thread-safe issue
From: "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx>
Date: Thu, 24 Mar 2011 20:29:36 -0400
Cc: kenj@xxxxxxxxxxxxxxxx, pcp@xxxxxxxxxxx
In-reply-to: <2118764545.3998.1300843691183.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
References: <1300826238.12077.130.camel@xxxxxxxxxxxxxxxx> <2118764545.3998.1300843691183.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Mar 23, 2011 at 12:28:11PM +1100, Nathan Scott wrote:
> 
> ----- Original Message -----
> > In several of places within libpcp we return a pointer to a static
> > buffer ... since the buffer contents are not constant, this is not
> > thread-safe.
> > 
> > The routines are: pmAtomStr, pmTypeStr, pmUnitsStr, pmIDStr,
> > pmInDomStr,
> > __pmLogName, pmNumberStr, __pmPDUTypeStr and __pmTimezone.
> > 
> > There are 3 possible fixes:
> > 
> > 1. UCB-style, add func_r variants with an additional parameter that is
> > the buffer of an assumed sufficient size.
> > 
> > 2. Change the API semantics to return malloc'd buffers that the caller
> > must free.
> > 
> > 3. POSIX-style, add new functions for each, with an additional pair of
> > arguments at the beginning to identify a caller allocated buffer and
> > the length of that buffer (e.g. strftime) ... and discourage the use of
> > the old functions.
> > 
> > Thoughts?
> > 
> > I really don't like 1. or 3. as they confuse and pollute the API and
> 
> I really don't like 2. :)  It forces malloc all the time which can become
> costly for frequent calls (none of the above really in that category,
> although maybe __pmTimezone is) but sets a poor precedent for others to
> follow.  Not a big fan of Maxs thread local suggestion either, fwiw.

Not to mention that malloc can be costly in a multi-threaded environment.

Jeff.

-- 
NT is to UNIX what a doughnut is to a particle accelerator.

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