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

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Wed, 22 Jul 2009, Renzo Davoli wrote:

> 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.

It is an issue with the *kernel-userspace interface*: how should 
checkpoint/restart deal with preserving a pid or communicating to a 
process that its pid has changed?  This issue needs agreement between 
kernel and libc communities, including the several different libcs used 
with the Linux kernel, and the linux-api list is the right place to find 
people interested in the interface and build the consensus.  Sometimes the 
solution to a problem may lie entirely on the kernel side or entirely on 
the libc side, but it needs to be discussed in the correct place that 
brings the two sides together first in order to conclude what the correct 
solution is.

The latest checkpoint/restart patch series, a series of 60 patches, 
appeared on linux-api today, and it includes a clone_with_pids syscall 
(patch 17/60) to preserve the pid on restart instead of changing it.  If 
you believe a different solution is appropriate, you need to be in there 
in the linux-api discussion (sent also to some other kernel mailing 
lists), making the case for your solution and persuading people there that 
a purely libc API for this is appropriate and that this API should take a 
particular form; without such consensus in the right place, implementing 
the API in libc is premature.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx