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

[Renzo Davoli <renzo@xxxxxxxxxxx>]

First of all, thank you for your prompt reply.

On Tue, Jul 21, 2009 at 04:00:23PM +0000, Joseph S. Myers wrote:
> On Mon, 20 Jul 2009, Renzo Davoli wrote:
> > Unfortunately in some cases this is not true. Sometimes people want to
> > block (freeze) processes, save their memory state and restart them
> > later. In this way new pids get assigned (cached getpid values became 
> > inconsistent).
> Is this support present in kernel.org kernels?  I know there have been 
> discussions of such features but haven't followed the details.
It is not a Kernel issue. The problem is about the mapping between
the library call named getpid and the system call named in the same way:
getpid.

The interface of both getpid's is the same and has not changed for uncountable
years, both as a system call and as a library call, it is not a problem of API.

The problem is that in some point of time the implementation of the 
glibc call added a cache to store the value of a previous getpid for
all later calls.
Unfortunately this change broke some programs (e.g. cryopid is not
working properly), we are having similar problems.

There is a thread on LKML about getpid caching, 
see http://lkml.org/lkml/2004/6/5/88
Linus Torvalds was *against* getpid caching.
This was an "optimization" decided by glibc people regardless kernel
developers opposition.

My humble opinion is that Linus is right, that "optimization" should be
eliminated from glibc code: eglibc could fix this glibc problem like it is
already doing for other problems.

At least eglibc should give us a way to circunvent the idiosyncracies of
such a glibc "optimization", i.e. a fuction to clean the getpid buffer.

Thank you.
		renzo