On 11/03/15 10:06, Paul Sandoz wrote:
On Mar 10, 2015, at 4:41 PM, Roger Riggs <[email protected]> wrote:
Hi Paul,
On 3/10/2015 11:22 AM, Paul Sandoz wrote:
Any sub-type of Process that does not override getPid will essentially result
in that USO being propagated to many ProcessHandle methods that depend on the
PID (parent, children, allChildren, info, compareTo). That effectively renders
ProcessHandle almost useless for sub-types outside of our control that that not
been updated.
For those methods, the default behavior can be specified, except for compareTo
they already have return values that allow for the fact that the information may
not be available, either due to OS restrictions (permissions) or is not
provided.
Empty lists for children, nulls returned from info, and even allowing for an
unavailable parent.
That's a separate issue.
If i get a ProcessHandle given to me, i do not know it's source, i dunno if
it's gonna barf if i operate on it.
It can be a goal to never throw UOE, to achieve that, the behaviors of all of
the methods
(of Process) would be defined to have outputs that have to be checked by the
app;
hence the reference to nulls; empty lists, etc.
In many cases already, if the OS does not provide values or the OS permissions
do not permit
it then the values returned are empty (instead of throwing exceptions).
That design can be extended to the external subclasses by specifying the
default behavior
of Process and then defining the behaviors of Processes created by
ProcessBuilder.
I still think that conflates the "OS says no" and the "Subtype of Process does not
support the contract of ProcessHandle".
Process as designed feels kind of limited and we are stuck with that.
ProcessHandle is then also limited by Process extending it. Thus my inclination
is still for Process to not extend from ProcessHandle, let's keep then at a
distance.
I think this design should work out cleaner. There can be just a single
point where UOE can be thrown, from toHandle().
My inclination, with this design, is to remove Process.getPid(), since
the pid can be retrieved from the handle. This should be possible since
Process.getPid() is @since 1.9.
For arguments sake let's say we go with that approach:
public abstract class Process {
can be removed, no?
long getPID() throws USO { throw new USO; }
I think ProcessHandle needs a protected constructor, otherwise it cannot
be implemented outside of the platform. Or is this the intent? In which
case Process.getPid() may need to remain.
// Not final but effectively so for subtypes outside of package since
public construction of ProcessHandle
// is not possible
ProcessHandle toHandle() throws USO { return ProcessHandle.of(getPID()); }
CF<Process> onProcessExit() { ... } // crappy default
}
public abstract class ProcessHandle {
ProcessHandle() {}
public abstract long getPid(); // Does not throw USO
}
With such an approach if one has a ProcessHandle instance will the native PID
always be available?
Paul.
-Chris.
