What happened to System/Process.getPid() ?
martinrb at google.com
Thu Nov 15 12:26:17 UTC 2012
I was half-planning on implementing getPid back in 2008 but ran out of time.
My intent was to have the pid simply be a String, even though on common
platforms an int would suffice, leaving enough room for unusual
implementations to get what they want.
Essentially, return in String form what humans would use to identify
processes on the machine, which might be e.g. "NODENAME:NNN" on a cluster.
On Thu, Nov 15, 2012 at 2:08 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
> On 15/11/2012 01:11, Rob McKenna wrote:
>> Hi Thomas,
>> Don't ask me why, but for some reason this mail just landed in my client
>> now. (this happens a lot on this mailing list for some reason)
>> getPid() is still on the todo list at the moment. Once I clear my plate a
>> little I'll follow up on it.
> I just received too, and dozens of other mails so there must have been a
> blockage somewhere.
> I think the issue with 4244896 is just that you didn't change the synopsis
> to reflect what the changes were actually about. It would be good to link
> it to the bug suggesting a getPid equivalent. You probably know this but a
> getPid and perhaps a getCurrentPid requires great care. We cannot assume
> that it can be represented by an int or long, it needs to allow for
> environment that might not have the notion of process as we know it, also
> needs consideration of environment where they may be several VMs running in
> the same process. So lots of wriggle room in the spec, otherwise it will
> not be implementable everywhere.
More information about the core-libs-dev