Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Hubertus Franke <frankeh@watson.ibm.com>]

Serge E. Hallyn wrote:
> Quoting Paul Jackson (pj@sgi.com):
> 
>>An additional per-task attribute, set by a batch manager typically
>>when it starts a job on a checkpointable, restartable, movable
>>"virtual server" connects the job parent task, and hence all its
>>descendents in that job, with a named kernel object that has among its
>>attributes a pid range.  When fork is handing out new pids, it honors
>>that pid range.  User level code, in the batch manager or system
>>administration layer manages a set of these named virtual servers,
>>including assigning pid ranges to them, and puts what is usually the
>>same such configuration on each server in the farm.
> 

And that's how we implement this.
The difference is that the pidrange-id is assigned on the fly,
that is when the virtual server is created or recreated after restart.

This, as described in my previous note, is more scalable, because I don't have
to do a global pidrange partitioning.
global pidrange partitioning has implications, for instance what if I simply
want to freeze an app only to restart it much later. This would freeze that
range autmatically.

On process restart, we force fork to use a particular <pidspace/pid> for its
kernel pid assignment, rather then searching for a free one.

-- Hubertus