Re: [issues] getpid: to cache or not to cache

[Renzo Davoli <renzo@xxxxxxxxxxx>]

On Sun, Aug 02, 2009 at 04:12:51PM +0400, Maxim Kuvyrkov wrote:
> By the way, the manpage for clone(2) suggests a suitable workaround for  
> programs that necessarily need the uncached pid value:
>
> <cut>
> BUGS
>        Versions of the GNU C library that include the NPTL thread\u2010
>        ing library contain a wrapper function  for  getpid()  that
>        performs  caching of PIDs.  In programs linked against such
>        libraries, calls to getpid() may  return  the  same  value,
>        even  when  the threads were not created using CLONE_THREAD
>        (and thus are not in the same thread group).   To  get  the
>        truth,  it may be necessary to use code such as the follow\u2010
>        ing
>
>            #include <syscall.h>
>
>            pid_t mypid;
>
>            mypid = syscall(SYS_getpid);
> </cut>

Maxim,

unfortunately we are trying to work on a general suspend and resume 
service and virtualization services.
We cannot ask to firefox or gcc to change their code to include workarounds
to the C library.

Anyway we are currently using something similar.
We use a library including a re-definition of getpid (and also raise had
the same problem) loaded as a LD_PRELOAD.

More specifically we have added this feature to our purelibc library,
the library for system call self virtualization.
so now:
export LD_PRELOAD=/usr/lib/libpurelibc.so
solves the problem (for dynamically linked executables).

Anyway, I agree with Linux Torvalds by saying that getpid caching is
a useless optimization (just for benchmarks).
You have cut&pasted here the BUG section of the clone(2) man page: 
so getpid cache is perceived as a BUG for some applications.
It is sad to spend our time to find out workarounds for useless optimizations,
or BUGs pretending to be optimizations. 

thank you
		renzo