Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Kyle Moffett <mrmacman_g4@mac.com>]

On Jan 17, 2006, at 11:19, Suleiman Souhlal wrote:
> Why does there need a separate pid space for each container?  You  
> don't really need one to make sure that only processes in the same  
> containers can see each other.

On Jan 17, 2006, at 11:03, Alan Cox wrote:
> This is an obscure, weird piece of functionality for some special  
> case usages most of which are going to be eliminated by Xen. I  
> don't see the kernel side justification for it at all.
>
> Maybe you should remap it the other side of the user->kernel  
> boundary ?

To answer both questions at the same time, this is to make it  
practical to reliably freeze and restore whole process-trees/jobs,  
possibly restarting or migrating to a different computer in-between.   
Such freeze/restore code is mostly possible now, except for programs  
that store a pid internally to send a signal to another process.  The  
usage would be something like this:

start:
	create container:
		run jobs

freeze
	for each process/thread in the container:
		send SIGSTOP to halt execution
	for each process in the container:
		store process data, filehandles, vpid, etc

restore:
	create container:
		iterate over the frozen processes in the freeze file:
			clone_with_pid(flags, original_vpid);
			adjust session, connect filehandles, etc
			remap shared memory, etc
			block on atomic "resume" variable in mmap-ed file
		
		set "resume" to 1

The end result is that you could freeze and resume _any_ process tree  
in a container, even ones that do weird things with filehandles,  
sockets, pids, etc.  Personally I would find this useful to migrate  
an extensive memory-leak-debugging session in a large application  
over from laptop to desktop or vice versa.  You could also freeze/ 
migrate/restore a whole X session (not including the X process  
itself, but all the client apps).  You could not do this at all for  
statically-linked applications without kernel support, and it would  
be rather inefficient to do even for dynamically-linked ones.

The one other option would be to allow opening a file /proc/$PID/ 
control, to which you could write a signal number, and require  
freezable programs to use that interface to reliably send signals  
(This also makes signals non-racy if you're reusing all 60000+ pids  
on a regular basis).  This has the disadvantage of not even working  
for existing dynamically-linked programs either..

Cheers,
Kyle Moffett

--
There is no way to make Linux robust with unreliable memory  
subsystems, sorry.  It would be like trying to make a human more  
robust with an unreliable O2 supply. Memory just has to work.
   -- Andi Kleen