RFR 9: 8003488 Add Process.getPid
martinrb at google.com
Wed May 14 23:14:12 UTC 2014
I am OK with using longs despite my academic worries about the year 2100.
On Wed, May 14, 2014 at 1:03 PM, roger riggs <roger.riggs at oracle.com> wrote:
> For system local process identifiers, all of the systems I'm aware are
> 32 bit integers, printed and parsed in decimal for ease of use.
> I would describe the native pid as:
> The native process id is the identifier commonly used in the
> operating system APIs and commands to show the status of and
> manage processes; typically a decimal number with 1 to 6 digits.
> The Apollo system used a string to be able to uniformly address
> processes across hosts and it was parseable to host and decimal pid.
> I anticipate a ProcessHandle type with methods to check if the process is
> to destroy it, wait for it to terminate, etc.
> It would be a supertype of Process but not all ProcessHandles would be
> since they were not created by Process/ProcessBuilder and have different
> security concerns and checks.
> ProcessHandles would be returned from factory methods like current(long
> or current(). If Java is ported to a system with non-numeric process
> it would be viable to add appropriate factory methods.
> On 5/12/2014 5:01 PM, Alan Bateman wrote:
>> On 12/05/2014 20:44, roger riggs wrote:
>>> Please review and comment on this long requested addition to provide the
>>> native process id of a spawned Process.
>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488
>> I think the representation of the pid needs consideration - we need to be
>> happy that using a long is the right thing to do and won't cause us
>> problems in the future and won't conflict with other APIs that we might add
>> in this area.
>> In terms of spec then it might be helpful to say a bit more to define a
>> "native process id", even in an abstract way.
More information about the core-libs-dev