On Sat, Apr 11, 2015 at 11:13 AM, Roger Riggs <roger.ri...@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
