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@oracle.com> wrote:
Hi,
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 alive, to destroy it, wait for it to terminate, etc. It would be a supertype of Process but not all ProcessHandles would be processes 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 pid) or current(). If Java is ported to a system with non-numeric process identifiers it would be viable to add appropriate factory methods.
Roger
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.
-Alan