Hi Roger,
On 12/1/2015 6:05 PM, Roger Riggs wrote:
Hi Joe,
I do not know of any specific skew issues at the resolutions used. For
example,
Linux records the start time in ticks (1/60th to 100th of a second),
not the full resolution
of the time of day clock. Typically, the child start time is at least
a bit later
than the parent. If the maximum possible skew was known or estimated,
the comparison
could take that into account. For example, I would expect the skew
across processors
to be less than 1sec (or more likely 10ms) or there would be bigger
issues among native processes.
Okay; if the start time precision is relatively coarse that reduces the
hazard of a problem here.
I think it is reasonable to go ahead with the current changes if is this
kind of issue comes up in the future, a "fuzz" factor is determined and
taken into consideration.
Thanks,
-Joe
Thanks, Roger
On 12/1/15 8:54 PM, Joseph D. Darcy wrote:
Hi Roger,
Looks fine.
Do you know if there are clock skew issues to be concerned with if
the parent and child are spawned on different CPUs?
Thanks,
-Joe
On 12/1/2015 5:49 PM, Roger Riggs wrote:
Please review this change in ProcessHandle to validate parent pids
provided by the OS.
Children of a process have start times that are the same or later
than the parent.
The implementation of descendants(), and children(), and getParent()
are updated to validate the parent pid.
The problem is most pronounced on Windows; the parent pid reported
for a
process may be stale if the parent exited. The validation is
applied in
platform neutral code and used on all platforms. Platform specific
code
is used on Windows for getParent(); the Linux platforms do the right
thing.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8143876
Thanks, Roger
