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 = ...
p.on
Hi Peter,
If delegating to another Process and not needing to return the CF
then the overridden implementation might be:
public CompletableFuture onExit() {
return delegate.onExit();
}
The .thenApply(ph -> this) would be needed only for the return value to
be CF.
The explanatio
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
implem
...in addition, I would also try not to swallow interrupts in default
implementation:
public CompletableFuture onExit() {
return CompletableFuture.supplyAsync(() -> {
boolean interrupted = false;
while (true) {
try {
waitFo
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 java.util.concurrent.ForkJoinPool#commonP
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 i
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 processes,
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 sp
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.
Indee
On 12 Mar 2015, at 13:56, 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 ex
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 ProcessHand
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 ProcessHan
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.
$.0
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 Pro
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
b/src/java.base/share/
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 subclas
On Mar 10, 2015, at 4:41 PM, Roger Riggs 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,
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 a
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
Proce
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 th
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 1
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:
c
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 outsid
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 w
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 which case Process.getPid() may need to
On Mar 11, 2015, at 12:12 PM, Peter Levart wrote:
>>
>> CF 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 ProcessHandle, we can skip this
On Mar 11, 2015, at 11:29 AM, Chris Hegarty 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 also limit
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 beh
On 11/03/15 10:06, Paul Sandoz wrote:
On Mar 10, 2015, at 4:41 PM, Roger Riggs 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
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 specificati
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 a
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
impl
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 wrote:
2) I know there has been a lot of discussion about the use of CF,
but I have a few more comments:
a) Bo
On 03/10/2015 10:50 AM, Paul Sandoz wrote:
On Mar 6, 2015, at 7:58 PM, Roger Riggs 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 t
On Mar 10, 2015, at 3:16 PM, Roger Riggs wrote:
> On 3/10/2015 5:50 AM, Paul Sandoz wrote:
>> On Mar 6, 2015, at 7:58 PM, Roger Riggs 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 onProcessEx
Hi Paul,
On 3/10/2015 5:50 AM, Paul Sandoz wrote:
On Mar 6, 2015, at 7:58 PM, Roger Riggs 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 U
0
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,
The problem could be isolated to compareTo by defining the
ordering if
getPid
On Mar 6, 2015, at 7:58 PM, Roger Riggs 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 the implementati
ust
startInstant and pid.
Jason
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
e-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 for getPid returning the native
os process identifier.
Yes,
Jason
> 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/1
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
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 (
JDK-80
Chris
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 sa
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..
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,
http://cr.openjdk.java.
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 C
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 allo
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?
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 cf =
process.completableFuture();
>
>...but it doesn't hi
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 cf = process.completableFuture();
>
>...but it doesn't hinder the use of above 'cf' quite so much as 'len'
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 cf = process.completableFuture();
>
>...but it doesn't hinder the use of above 'cf' quite so much as 'len' in List
example above, since 'T' in Completa
On Feb 13, 2015, at 1:36 PM, Peter Levart 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 len = Arrays.asList(1, 2, 3)
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 wrote:
Hi,
The Process and
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 wrote:
> Hi,
>
> The Process and ProcessHandle API javadoc has been updat
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
u
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 q
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 wrote:
ProcessHandle.Info provides a startTime and totalTime. But it seems odd and
incon
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 be
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 that
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 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 bet
(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
terminate
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 -
c
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 m
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 implem
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 s
On Feb 10, 2015, at 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 cla
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 fe
On 9 February 2015 at 23:44, David M. Lloyd 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 you
> went with a raw
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 betw
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 secu
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 Pr
74 matches
Mail list logo