Looks good to me.
Thanks,
Masayoshi
On 4/11/2014 10:46 PM, Volker Simonis wrote:
Hi Jonathan,
thank you for fixing all the remaining issues. From my point of view
this change looks good now.
@Masayoshi: can I please get a final approval from you for pushing the
change? I also want to
On 04/11/2014 06:49 PM, roger riggs wrote:
Hi Peter,
We do know the PIDs of the processes that we care about but are unwilling
to pay the cost of waiting for them individually.
For the escapees, Process could resort to an individual thread
invoking waitpid(n).
Thanks, Roger
Yes, it could.
Hi Martin, Roger,
Just a thought. Would it be feasible to have two (ore more) built-in
strategies, selectable by system property? A backwards compatible tread
per child, using waitpid(pid, ...), a single reaper thread using
waitpid(-1, ...), maybe also single threaded strategy accessible only
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8039816
Thank you.
Shura
Change looks fine.
Thanks
Max
On Apr 14, 2014, at 17:48, Alexandre (Shura) Iline alexandre.il...@oracle.com
wrote:
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8039816
Thank you.
Looks good to me Shura. I can sponsor this for you ( if needed ).
-Chris.
On 14/04/14 10:48, Alexandre (Shura) Iline wrote:
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8039816
Thank you.
On 4/14/14, 2:00 PM, Chris Hegarty wrote:
Looks good to me Shura. I can sponsor this for you ( if needed ).
Thank you.
Shura.
-Chris.
On 14/04/14 10:48, Alexandre (Shura) Iline wrote:
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/
On 14/04/2014 10:48, Alexandre (Shura) Iline wrote:
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8039816
This looks okay to me too.
-Alan
Hello!
It was reported that the error message in an exception is missing a space.
Grep found a couple of other places with the same misformatting.
Can I please have a review of the trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8009637
WEBREV:
On 14/04/2014 12:36, Ivan Gerasimov wrote:
Hello!
It was reported that the error message in an exception is missing a
space.
Grep found a couple of other places with the same misformatting.
Can I please have a review of the trivial fix?
BUGURL:
Thanks!
On 14.04.2014 15:55, Alan Bateman wrote:
On 14/04/2014 12:36, Ivan Gerasimov wrote:
Hello!
It was reported that the error message in an exception is missing a
space.
Grep found a couple of other places with the same misformatting.
Can I please have a review of the trivial fix?
Looks good Ivan!
best,
-- daniel
On 4/14/14 1:36 PM, Ivan Gerasimov wrote:
Hello!
It was reported that the error message in an exception is missing a space.
Grep found a couple of other places with the same misformatting.
Can I please have a review of the trivial fix?
BUGURL:
Hello!
The test EarlyTimeout.java failed again, now with message elapsed time
981 is less than timeout 1000.
The root cause seems to be non-accurate time measurement in Windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx
Because of this we can achieve this
Hi Martin,
A new API is needed, overloading the current Process API is not a good
option.
Even within Process a new method will be needed to destroy the
subprocess and all
of its children maintain backward compatibility.
Are there specific OS features that need to be exposed to applications?
Hi Peter,
The new API to handle process trees and processes not spawned by the
Java process
also will need a way to wait for exit status and destroy children so I'm
not sure the
issue goes away. It too will need to co-exist with non-JDK libraries
that spawn and handle
their own children.
A
Where does the requirement to manage grandchild processes actually come
from? I'd hate to see the ability to nicely terminate immediate child
processes lost just because it was difficult to implement some grander
scheme.
On 04/14/2014 08:49 AM, roger riggs wrote:
Hi Martin,
A new API is
Hi,
Jtreg, for example, needs a reliable way to cleanup after tests.
We've had a variety of problems with stray processes left over because
there is no visibility nor reliable way to identify and kill them.
Roger
On 4/14/2014 10:31 AM, David M. Lloyd wrote:
Where does the requirement to
Are you by any chance running on a VM? We have seen issues like this
before, see
https://bugs.openjdk.java.net/browse/JDK-7148829
( as of yet still unresolved)
-Chris.
On 14/04/14 14:21, Ivan Gerasimov wrote:
Hello!
The test EarlyTimeout.java failed again, now with message elapsed time
On 04/14/2014 03:50 PM, roger riggs wrote:
Hi Peter,
The new API to handle process trees and processes not spawned by the
Java process
also will need a way to wait for exit status and destroy children so
I'm not sure the
issue goes away. It too will need to co-exist with non-JDK libraries
On 4/14/2014 2:48 AM, Alexandre (Shura) Iline wrote:
Hi.
I'd like to ask for review of this fix:
http://cr.openjdk.java.net/~shurailine/8039816/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8039816
This change looks fine. Thanks for these test cleanup.
Mandy
On 4/14/2014 6:21 AM, Ivan Gerasimov wrote:
Hello!
The test EarlyTimeout.java failed again, now with message elapsed
time 981 is less than timeout 1000.
The root cause seems to be non-accurate time measurement in Windows:
On 04/14/2014 04:37 PM, roger riggs wrote:
Hi,
Jtreg, for example, needs a reliable way to cleanup after tests.
We've had a variety of problems with stray processes left over because
there is no visibility nor reliable way to identify and kill them.
Roger
Hi Roger,
If you want to reliably
On 04/14/2014 10:54 AM, Peter Levart wrote:
On 04/14/2014 03:50 PM, roger riggs wrote:
Hi Peter,
The new API to handle process trees and processes not spawned by the
Java process
also will need a way to wait for exit status and destroy children so
I'm not sure the
issue goes away. It too will
On 04/14/2014 11:37 AM, Peter Levart wrote:
On 04/14/2014 04:37 PM, roger riggs wrote:
Hi,
Jtreg, for example, needs a reliable way to cleanup after tests.
We've had a variety of problems with stray processes left over because
there is no visibility nor reliable way to identify and kill them.
Hi, Ivan
This sounds like an issue we saw in FX a while ago with imprecise timers
on Windows. If it is, you might check out:
https://bugs.openjdk.java.net/browse/JDK-6435126
It describes a workaround to enable higher-precision timing on Windows
(using a long-sleeping daemon thread). That
Hi Peter,
We already have Process.destroy vs Process.destroyForcibly though the
implementations are identical.
I agree that for a general purpose API, using a nice polite approach
with the
children is needed. But I'm troubled, by the 'wait-a-while' technique.
That probably should be left
Thanks Mandy and Alan for the review.
webrev has been updated accordingly to
(1) Removed the basic.sh. The tests are now using test.jdk to access the
zipfs.jar directly
(2) Updated most of the class to package package, only
ZipFileSystemProvider (the spi interface)
and ZipInfo are
Thanks Chris!
It's very similar, though still different.
ReferenceQueue.remove(timeout) makes sure the timeout has fully elapsed,
using System.nanoTime().
Thus the test failure only indicates that nested time intervals measured
with nanoTime() and currentTimeMillis() can be inconsistent: The
On 14.04.2014 20:18, Mandy Chung wrote:
On 4/14/2014 6:21 AM, Ivan Gerasimov wrote:
Hello!
The test EarlyTimeout.java failed again, now with message elapsed
time 981 is less than timeout 1000.
The root cause seems to be non-accurate time measurement in Windows:
Thank you Brent for the pointer!
I think that using nanoTime() is simpler in this situation.
We don't really have to use currentTimeMillis(), so no need to make it
more reliable.
Sincerely yours,
Ivan
On 14.04.2014 21:22, Brent Christian wrote:
Hi, Ivan
This sounds like an issue we saw in
On 14/04/2014 18:52, Xueming Shen wrote:
Thanks Mandy and Alan for the review.
webrev has been updated accordingly to
(1) Removed the basic.sh. The tests are now using test.jdk to access
the zipfs.jar directly
(2) Updated most of the class to package package, only
ZipFileSystemProvider (the
On 4/14/2014 11:26 AM, Ivan Gerasimov wrote:
Actually, zero tolerance should be sufficient now even for Windows
platform.
Measuring the time with nanoTime() should make the inner and outer
time intervals consistent.
I've added the tolerance just to play safer.
I can remove it.
That'd be
Hi,
webrev has been updated to use the name space jdk.nio.zipfs.
http://cr.openjdk.java.net/~sherman/8038500/webrev/
-Sherman
On 4/14/14 12:15 PM, Xueming Shen wrote:
On 4/14/14 11:56 AM, Alan Bateman wrote:
On 14/04/2014 18:52, Xueming Shen wrote:
Thanks Mandy and Alan for the review.
On 04/15/2014 12:04 AM, David M. Lloyd wrote:
There's already such a race in current implementation of
Process.terminate(). It admittedly only concerns a small window between
process exiting and the reaper thread managing to signal this state to
the other threads wishing to terminate it at the
34 matches
Mail list logo
