On 7/29/15 11:36 AM, Volker Simonis wrote:
!! ProcessHandleImpl_unix: 709-738: I still disagree with returning
truncated or incomplete
values for the executable or arguments.
Can anyone be a tie-breaker (with a good rational and suggestion for how an
application can use the data).
As I wrote, I agree to hear other opinions here.
All I want to say that this truncated data is actually what 'ps' is
reporting on Solaris since decades and people seem to be happy with
it. As use case I can imagine logging or monitoring (something like
'top' in Java) where this data will be just good enough.
We could specially mark possibly incomplete data by extending the Info
object with functions like commandIsExact() or argumentsIsPrecise().
But notice that we can not statically preset these values per
platform. For example on Solaris, the 'command()' would return a
precise value for processes with the same uid like the VM but only
inaccurate values for all other processes. The "arguments()" would be
always inaccurate on Solaris/AIX.
It seems like there are cases where either exact or only approximate information
is available. And as you observed, you might get one or the other on the same
platform, depending on the UID. It also might depend on process state; I believe
that some information becomes inaccessible when the process enters the zombie state.
I don't think we should simply ignore one case or the other, but I also don't
think we should try to cram the different information into the same API.
The current ProcessHandle.Info api has
Optional<String> command()
Optional<String[]> arguments()
It sounds to me like Roger wants these to contain only exact information. That
seems reasonable, and this probably needs to be specified more clearly to
contrast with what's below.
On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a single
string which appears to be the concatenation of the arguments (maybe including
the command name). It's also truncated to fit PRARGSZ. It doesn't make sense to
me to try to return this as a String[], as the zeroth element of that array, and
certainly not parsed out into "words". So maybe instead we should have a
different API that returns an imprecise command line as a single string:
Optional<String> cmdline()
(Naming bikeshed TBS). The semantics would be that this is the process' command
and arguments concatenated into a single string (thus potentially losing
argument boundaries) and also possibly truncated based on platform
(COUGHsolarisCOUGH) limitations. It's certainly useful for printing out in a ps,
top, or Activity Monitor style application, for informational purposes.
If this were implemented, then on Solaris, command() and arguments() would
always return empty optionals.
I'm not sure what this should be if the exact information is available. It would
be inconvenient if something that just wanted to print out an approximate
command line had to check several different APIs to get the information. Maybe
cmdline() could assemble the information from exact data if it's is available,
by concatenating the Strings from command() and arguments(), as a convenience to
the caller. But I could go either way on this.
Not sure this counts as a tie-breaker, but it might be a reasonable way forward.
s'marks
might be convenient if this
