Hi Rogger,
Now that the method has a non-throwing default implementation, what do
you think of the following implementation note for Process.onExit():
* @implNote
* The default implementation of this method employs a thread from
* {@link
...in addition, I would also try not to swallow interrupts in default
implementation:
public CompletableFutureProcess onExit() {
return CompletableFuture.supplyAsync(() - {
boolean interrupted = false;
while (true) {
try {
On 03/13/2015 02:35 PM, Roger Riggs wrote:
Hi Peter,
Right, that is the preferred handling.
In this case, the forwarded interrupt will be passed back to the
Thread from the ThreadPool
and is disregarded there.
I thought that too, but is not necessarily so. For example:
Process p = ...
Hi Peter,
Right, that is the preferred handling.
In this case, the forwarded interrupt will be passed back to the Thread
from the ThreadPool
and is disregarded there.
Roger
On 3/13/2015 3:56 AM, Peter Levart wrote:
...in addition, I would also try not to swallow interrupts in default
Hi Peter,
If delegating to another Process and not needing to return the CFsubtype
then the overridden implementation might be:
public CompletableFutureProcess onExit() {
return delegate.onExit();
}
The .thenApply(ph - this) would be needed only for the return value to
be
Hi Peter,
On 3/10/2015 12:47 PM, Peter Levart wrote:
On 03/10/2015 02:55 PM, Roger Riggs wrote:
ProcessHandle is designed to not to have an external implementations
(the constructor is package private).
I don't see a purpose in this. You can still subclass it freely,
because you can
This is looking good, still looking at the detail… just a quick comment.
It may be possible to remove the UOE from Process.onExit, if you implement the
“never to be used” default without using ProcessHandle?
diff --git a/src/java.base/share/classes/java/lang/Process.java
On 03/11/2015 08:58 PM, Roger Riggs wrote:
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
That's strange. Process no longer extends ProcessHandle (which is
visible in apidraft), but
On 03/12/2015 03:10 PM, Chris Hegarty wrote:
...but there is no ProcessHandle.onExit() (there is a
ProcessHandle.completableFuture()). Looks like Process and ProcessHandle are from
different stories?
I think you must be suffering from browser cache issues? I don’t see these
problems.
Seems reasonable since the choice of threads that are used to achieve
the async behavior
is an (undocumented) implementation detail.
On 3/12/2015 9:09 AM, Chris Hegarty wrote:
This is looking good, still looking at the detail… just a quick comment.
It may be possible to remove the UOE from
Hi Peter,
On 3/12/2015 9:56 AM, Peter Levart wrote:
On 03/11/2015 08:58 PM, Roger Riggs wrote:
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
That's strange. Process no longer extends
On 03/12/2015 02:39 PM, Roger Riggs wrote:
Hi,
Just a thought, it might be useful to introduce a public subtype of
Process that is
returned from ProcessBuilder for which the guarantees about behavior
could be
tighter (no UOEs). It would also provide a place to document the
behaviors
now
Hi,
Just a thought, it might be useful to introduce a public subtype of
Process that is
returned from ProcessBuilder for which the guarantees about behavior
could be
tighter (no UOEs). It would also provide a place to document the
behaviors
now spread across ProcessBuilder and Process.
On 12 Mar 2015, at 13:56, Peter Levart peter.lev...@gmail.com wrote:
On 03/11/2015 08:58 PM, Roger Riggs wrote:
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
That's strange. Process no
Hi Peter,
Introducing a public Process subtype would not be a binary compatible
change;
the return type of ProcessBuilder.start can not be narrowed.
As you surmised, a different start method would be needed on ProcessBuilder.
Since ProcessBuilder is the preferred mechanism to created
On 03/12/2015 09:41 PM, Roger Riggs wrote:
Hi Peter,
Introducing a public Process subtype would not be a binary compatible
change;
the return type of ProcessBuilder.start can not be narrowed.
As you surmised, a different start method would be needed on
ProcessBuilder.
Since ProcessBuilder
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
On 03/10/2015 02:55 PM, Roger Riggs wrote:
ProcessHandle is designed to not to have an external implementations
(the constructor is package private).
I don't see a purpose in this. You can still subclass it freely, because
you can subclass Process which is-a ProcessHandle. I think it can be
On Mar 10, 2015, at 4:41 PM, Roger Riggs roger.ri...@oracle.com 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
Hi,
The recommendations have been applied to the javadoc and the sandbox
JDK-8046092-branch.
http://cr.openjdk.java.net/~rriggs/ph-apidraft/
Some operations on a Process take an extra dereference due to the
delegation to ProcessHandle.
For example, getting the cputime or startTime of
On Mar 11, 2015, at 11:29 AM, Chris Hegarty chris.hega...@oracle.com wrote:
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
On Mar 11, 2015, at 12:12 PM, Peter Levart peter.lev...@gmail.com wrote:
CFProcess onProcessExit() { ... } // crappy default
I don't know. There are two ways to get that behaviour then.
Process.onProcessExit() and Process.toHandle().onExit(). If Process is not a
subtype of
On 03/11/2015 11:06 AM, Paul Sandoz wrote:
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
On 11/03/15 10:06, Paul Sandoz wrote:
On Mar 10, 2015, at 4:41 PM, Roger Riggs roger.ri...@oracle.com 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
On 11/03/15 11:34, Peter Levart wrote:
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
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
On 03/11/2015 12:51 PM, Chris Hegarty wrote:
On 11/03/15 11:34, Peter Levart wrote:
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
can be removed, no?
long getPID() throws USO { throw new USO; }
I think ProcessHandle needs a protected constructor, otherwise it
cannot be implemented
Hi,
I think the 'convenience' methods for onExit() and getPid() are
useful/desirable on Process.
It should not be necessary to shuttle over to ProcessHandle to do basic
functions on the Process.
Roger
On 3/11/2015 7:34 AM, Peter Levart wrote:
On 03/11/2015 11:29 AM, Chris Hegarty wrote:
Hi,
Also, is there a proposal for Process.compareTo?
It can be left out for the status quo, but otherwise the issue with
getPid()/toHandle and UOE remains.
Though the previously described artificial pid workarounds can be used.
Roger
On 3/11/2015 7:57 AM, Peter Levart wrote:
On 03/11/2015
On Mar 6, 2015, at 7:58 PM, Roger Riggs roger.ri...@oracle.com wrote:
2) I know there has been a lot of discussion about the use of CF,
but I have a few more comments:
a) Both onExit and onProcessExit are implemented to unconditionally
throw UOE. Is the intention to make
...@oracle.com; jason_mehr...@hotmail.com
CC: core-libs-dev@openjdk.java.net
Subject: Re: JEP 102 Process Updates revised API draft
On 09/03/15 14:28, Roger Riggs wrote:
Hi,
The problem could be isolated to compareTo by defining the
ordering if
getPid
throws UOE and without diluting the spec
Hi Peter,
Differing design approaches...
On 3/10/2015 12:37 PM, Peter Levart wrote:
On 03/10/2015 10:50 AM, Paul Sandoz wrote:
On Mar 6, 2015, at 7:58 PM, Roger Riggs roger.ri...@oracle.com wrote:
2) I know there has been a lot of discussion about the use of CF,
but I have a few more
On 03/10/2015 10:50 AM, Paul Sandoz wrote:
On Mar 6, 2015, at 7:58 PM, Roger Riggs roger.ri...@oracle.com wrote:
2) I know there has been a lot of discussion about the use of CF,
but I have a few more comments:
a) Both onExit and onProcessExit are implemented to unconditionally
On Mar 10, 2015, at 3:16 PM, Roger Riggs roger.ri...@oracle.com wrote:
On 3/10/2015 5:50 AM, Paul Sandoz wrote:
On Mar 6, 2015, at 7:58 PM, Roger Riggs roger.ri...@oracle.com wrote:
2) I know there has been a lot of discussion about the use of CF,
but I have a few more comments:
Hi Peter,
On 3/10/2015 2:57 PM, Peter Levart wrote:
Hi Roger,
Thanks for bearing with me...
And me, as I find the route among the language, type system,
compatibility issues,
and os intricacies.
On 03/10/2015 06:27 PM, Roger Riggs wrote:
I think current ProcessHandle is a mix of
On 03/10/2015 06:32 PM, Roger Riggs wrote:
Can you point me to the alternative Process implementations outside
the JDK?
I've seen a bit of flak about it not being the right API and if its
not right
we should not extend it.
Roger
This will continue to work, since it's just a wrapper around
Hi Roger,
Thanks for bearing with me...
On 03/10/2015 06:27 PM, Roger Riggs wrote:
I think current ProcessHandle is a mix of specification and partial
implementation that does not help in any way to hypothetical external
implementations. It effectively disables any consistent alternative
Date: Mon, 9 Mar 2015 14:43:20 +
From: chris.hega...@oracle.com
To: roger.ri...@oracle.com; jason_mehr...@hotmail.com
CC: core-libs-dev@openjdk.java.net
Subject: Re: JEP 102 Process Updates revised API draft
On 09/03/15 14:28, Roger Riggs wrote:
Hi
Subject: Re: JEP 102 Process Updates revised API draft
From: chris.hega...@oracle.com
Date: Fri, 6 Mar 2015 11:59:28 +
To: roger.ri...@oracle.com
CC: core-libs-dev@openjdk.java.net
Roger,
I’ve taken a look at these changes in the sandbox (
JDK-8046092
could now throw
UOE.
Ooh... I don't like this.
Has any consideration been given to getPid returning -1, if unknown or
the default implementation? Or would this be any better?
-Chris
Jason
Subject: Re: JEP 102 Process Updates revised API draft
From
Date: Mon, 9 Mar 2015 14:43:20 +
From: chris.hega...@oracle.com
To: roger.ri...@oracle.com; jason_mehr...@hotmail.com
CC: core-libs-dev@openjdk.java.net
Subject: Re: JEP 102 Process Updates revised API draft
On 09/03/15 14:28, Roger Riggs wrote:
Hi
@openjdk.java.net
Subject: Re: JEP 102 Process Updates revised API draft
On 09/03/15 14:28, Roger Riggs wrote:
Hi,
The problem could be isolated to compareTo by defining the ordering if
getPid
throws UOE and without diluting the spec for getPid returning the native
os process identifier.
Yes, that would
Jason
Subject: Re: JEP 102 Process Updates revised API draft
From: chris.hega...@oracle.com
Date: Fri, 6 Mar 2015 11:59:28 +
To: roger.ri...@oracle.com
CC: core-libs-dev@openjdk.java.net
Roger,
I’ve taken a look at these changes in the sandbox
Roger,
I’ve taken a look at these changes in the sandbox ( JDK-8046092-branch ).
Overall I welcome this addition.
Some comments, most of which I stuffed into a webrev based on your branch,
http://cr.openjdk.java.net/~chegar/process_comments/webrev/
1) ProcessHandle.compareTo() can drop the
Hi Chris,
Thanks for the comments.
On 3/6/2015 6:59 AM, Chris Hegarty wrote:
Roger,
I’ve taken a look at these changes in the sandbox ( JDK-8046092-branch ).
Overall I welcome this addition.
Some comments, most of which I stuffed into a webrev based on your branch,
Hi Chris,
Since getPid can throw UOE that means that compareTo could now throw UOE.
Jason
Subject: Re: JEP 102 Process Updates revised API draft
From: chris.hega...@oracle.com
Date: Fri, 6 Mar 2015 11:59:28 +
To: roger.ri...@oracle.com
CC
Hi Peter, et.al.,
I have no particular issue with adding waitForUninterruptibly but it
does not
help with the lack of scalability when handling many processes.
It requires a thread to do the waiting whether from a specific caller or
a thread pool
The intent of proving a Future/CF was to
On 02/13/2015 04:34 PM, Peter Levart wrote:
On 02/13/2015 04:18 PM, David M. Lloyd wrote:
I hesitate to mention it, but as someone who has been frustrated by
this same problem on numerous occasions I feel I must suggest that
maybe... having a completableFuture method should just be dropped?
Hi,
I am not sure everyone is aware of the sandbox repo that was setup, but it's
rather handy to see the changes:
http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/9a02f23ca186
On Feb 12, 2015, at 11:02 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi,
The Process and ProcessHandle API
On 02/13/2015 03:22 PM, Paul Sandoz wrote:
It*is* inconvenient for the user to have to use wildcards in specifying types:
CompletableFuture? extends Process cf = process.completableFuture();
...but it doesn't hinder the use of above 'cf' quite so much as 'len' in List
example above, since
On 02/13/2015 09:15 AM, Peter Levart wrote:
On 02/13/2015 03:22 PM, Paul Sandoz wrote:
It*is* inconvenient for the user to have to use wildcards in specifying types:
CompletableFuture? extends Process cf = process.completableFuture();
...but it doesn't hinder the use of above 'cf' quite so
On Feb 13, 2015, at 1:36 PM, Peter Levart peter.lev...@gmail.com wrote:
The use of wild cards in this context is generally discouraged because it
propagates to the caller as you have found out. You cannot do what you want
for the same reasons you cannot do this:
List? extends Number
On 02/13/2015 04:18 PM, David M. Lloyd wrote:
On 02/13/2015 09:15 AM, Peter Levart wrote:
On 02/13/2015 03:22 PM, Paul Sandoz wrote:
It*is* inconvenient for the user to have to use wildcards in
specifying types:
CompletableFuture? extends Process cf =
process.completableFuture();
...but
On 02/13/2015 11:02 AM, Paul Sandoz wrote:
Hi,
I am not sure everyone is aware of the sandbox repo that was setup, but it's
rather handy to see the changes:
http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/9a02f23ca186
On Feb 12, 2015, at 11:02 PM, Roger Riggs roger.ri...@oracle.com wrote:
Hi,
The Process and ProcessHandle API javadoc has been updated with the comments
and suggestions including the loose coupling of the Process from the
CompletableFutures
that are linked to process termination.
The improved implementation from Peter is incorporated and the method
descriptions
Thanks for the suggestions and confirmation that Duration is not a misuse
of that type for this purpose.
Roger
On 2/10/2015 2:38 AM, Stephen Colebourne wrote:
On 9 February 2015 at 23:44, David M. Lloyd david.ll...@redhat.com wrote:
ProcessHandle.Info provides a startTime and totalTime. But
Hi David,
Thanks for the suggestion:
Forcible process destruction is defined as the immediate termination of
a process, whereas regular destruction allows a process to shut down
cleanly.
It is very OS and application specific as to how and if an application
does cleanly exit
but adding
On Feb 10, 2015, at 12:25 AM, Roger Riggs roger.ri...@oracle.com wrote:
Hi,
After a protracted absence from working on JEP 102, the updated API draft
provides access to process hierarchies and individual process information;
as permitted by the OS. The relationship between Process and
Happy to see this!
In ProcessHandle.Info would it be possible to include the environment variables
of the process as well?
How does ProcessHandle.allChildren() behave when process A launches B which
launches C, and B terminates? Is C included in allChildren() of A?
Thanks,
/Staffan
On 10
On 02/10/2015 12:25 AM, Roger Riggs wrote:
Hi,
After a protracted absence from working on JEP 102, the updated API draft
provides access to process hierarchies and individual process
information;
as permitted by the OS. The relationship between Process and
ProcessHandle
is clarified and the
(not enough time for real review)
I support Peter's approach. I know of no way to be reliably notified of
process termination on unix without a dedicated thread per subprocess (unix
is broken!). Given that, we want to keep its stack size small, which is
where the 32k comes from. Maybe on 64-bit
Hi Roger
This looks great already. My feedback is about process destruction:
Why isn't ProcessHandle::isDestroyForcible a static method?
For ProcessHandle::destroy and Process::destroy, I'd like to propose
replacing
Whether the process represented by this Process object is forcibly
On 02/10/2015 02:02 PM, Peter Levart wrote:
On 02/10/2015 12:35 PM, Peter Levart wrote:
ProcessHandle.completableFuture().cancel(true) forcibly destorys
(destroyForcibly()) the process *and* vice versa: destory[Forcibly]()
cancels the CompletableFuture. I don't know if this is the best way -
Hi Peter,
On 2/10/2015 6:35 AM, Peter Levart wrote:
On 02/10/2015 12:25 AM, Roger Riggs wrote:
Hi,
After a protracted absence from working on JEP 102, the updated API
draft
provides access to process hierarchies and individual process
information;
as permitted by the OS. The relationship
Hi Peter,
Yep, I hadn't gotten to improving that part of the implementation yet.
The threading needs to be revised; System threads and the limited stack
were used currently
to monitor processes (on Linux) but are not suitable for evaluating
CompletionStages.
Switching to some form of Executor
Hi Anthony,
On 2/10/2015 2:12 PM, Anthony Vanelverdinghe wrote:
Hi Roger
This looks great already. My feedback is about process destruction:
Why isn't ProcessHandle::isDestroyForcible a static method?
The Process API is subclassable and in that case the subclass
should be able to control
Hi Staffan,
On 2/10/2015 4:53 AM, Staffan Larsen wrote:
Happy to see this!
In ProcessHandle.Info would it be possible to include the environment variables
of the process as well?
The API was intended to provide a degree of control over subprocesses,
but not
be a diagnostic tool, there are
On 02/10/2015 12:35 PM, Peter Levart wrote:
ProcessHandle.completableFuture().cancel(true) forcibly destorys
(destroyForcibly()) the process *and* vice versa: destory[Forcibly]()
cancels the CompletableFuture. I don't know if this is the best way -
can't decide yet. In particular, in the
On 02/09/2015 07:52 PM, Roger Riggs wrote:
On 2/9/15 6:44 PM, David M. Lloyd wrote:
Also, as a general comment, there isn't really a good explanation as
to what the difference is between a normal destroy and a forcible
destroy. Given that you've added an isDestroyForcible() method, I
think it
Hi David,
On 2/9/15 6:44 PM, David M. Lloyd wrote:
On 02/09/2015 05:25 PM, Roger Riggs wrote:
Hi,
After a protracted absence from working on JEP 102, the updated API
draft
provides access to process hierarchies and individual process
information;
as permitted by the OS. The relationship
On 9 February 2015 at 23:44, David M. Lloyd david.ll...@redhat.com wrote:
ProcessHandle.Info provides a startTime and totalTime. But it seems odd and
inconsistent that startTime is an Instant, yet totalTime is a raw long as
opposed to the arguably more consistent Duration. Is there a reason
On 02/09/2015 05:25 PM, Roger Riggs wrote:
Hi,
After a protracted absence from working on JEP 102, the updated API draft
provides access to process hierarchies and individual process information;
as permitted by the OS. The relationship between Process and ProcessHandle
is clarified and the
Hi,
After a protracted absence from working on JEP 102, the updated API draft
provides access to process hierarchies and individual process information;
as permitted by the OS. The relationship between Process and ProcessHandle
is clarified and the security model validated.
Both Processes and
72 matches
Mail list logo
