RFR 9: 8077350 Process API Updates Implementation Review

[Martin Buchholz]

On Sat, Apr 11, 2015 at 11:13 AM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

>  Hi Martin,
>
> Thanks for the review.
>
> On 4/11/2015 1:37 AM, Martin Buchholz wrote:
>
> Thanks for the huge effort.  I did a superficial review and it seems
> pretty good.  Of course, changing the Process good is high risk and some
> things will probably need fixup later.
>
>  On Unix, you seem to be identifying ProcessHandles by their pid.  What
> are you going to do about the problem of misidentifying Unix processes
> whose pid got recycled?  If you spin up a thread to call waitpid as soon as
> you create the ProcessHandle, the window is very short (and OSes avoid
> recycling pids immediately) so that's pretty safe, but it wastes a thread
> for each ProcessHandle!  I don't have a good answer.  Maybe record the
> start time of the process, where available?
>
> Getting the basic API and implementation in has taken too long, so I'm
> looking to get it general agreement
> and pushed and then I'd be happy to go back and include the start time in
> ProcessHandle.
> In the case of children() which already has to read /proc/pid/stat for the
> parent,
> the start time is inexpensively available also.  The spec for equals(),
> and compareTo is straightforward
> without the start time.  With the start time, either starttime has be
> exposed in the API/spec or
> be left 'implementation' dependent which is a poor spec.
> Only in the case of allProcesses() would the overhead increase
> significantly, it currently
> does not need to open /proc/pid for every process.
>

We have ancient "recycle pid" bugs and unavoidable races (kill(2) is
fundamentally racy).

                // There is a risk that pid will be recycled, causing us to
                // kill the wrong process!  So we only terminate processes
                // that appear to still be running.  Even with this check,
                // there is an unavoidable race condition here, but the
window
                // is very small, and OSes try hard to not recycle pids too
                // soon, so this is quite safe.

but in practice, we can assume that there will be a significant time gap
between reuses of the same pid, and so a check-then-act race will not
result in bad behavior, but you can't allow arbitrary time to elapse and
assume you're still dealing with the same process.


> Siginfo is only used with waitid as an output argument
>
>
Yes, my mistake.


>
> It seems you don't support sending arbitary signals, which is a little sad.
>
> I had not investigated any potential negative and unknowable effects of
> being able to send arbitrary signals.
> The implementation is easy to generalize, though it does not map to
> Windows well/at all.
> Would you propose it as an 'int' argument with no limitation? or what
> limits?
> I think it would be an additional method, the current
> destory/destroyForcibly.
>
>
The portable nature of Java has always hindered progress in functionality
in this area.

I haven't investigated in detail, but perl/emacs/python/tcl-expect manage
to achieve cross-platform functionality, perhaps by degraded functionality
on windows.

I very much do __not__ expect it to happen, but my wish would be to be able
to reimplement emacs in 100% java, including all the subprocess and
pseudo-terminal support required for:

http://www.gnu.org/software/emacs/manual/html_node/elisp/Processes.html