pcp
[Top] [All Lists]

Re: [pcp] Another thread-safe issue

To: kenj@xxxxxxxxxxxxxxxx
Subject: Re: [pcp] Another thread-safe issue
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Wed, 23 Mar 2011 12:28:11 +1100 (EST)
Cc: pcp@xxxxxxxxxxx
In-reply-to: <1300826238.12077.130.camel@xxxxxxxxxxxxxxxx>
----- 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.

I prefer 3 over 1.

> arbitrary apps can still invoke the thread-unsafe versions of the
> routines by error or oversight.

This can be mitigated by marking the unsafe versions with
"__attribute__((__deprecated__))"  (simply done, for an example:
http://levelpp.blogspot.com/2005/05/gcc-deprecation-attributes.html )
for GCC compilers, a bit like we do __PM_PRINTFLIKE perhaps.

cheers.

-- 
Nathan

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