Hi Stuart
I didn’t make my comment clear. You set interrupted as true when thread gets
interrupted. Here it's still going to wait until systemStub is not null. Why do
you still need interrupt current thread in this case.
Thank you
Tristan
On Jan 30, 2014, at 11:24 AM, David Holmes wrote:
>> h
On 1/29/14 8:50 PM, Tristan Yan wrote:
Looks like in you new webrev. The wait will continue to go loop until
systemStub is not null. If it’s what you meant to do that?
Yes. In the previous webrev, systemStub started off as null and made a single
transition to non-null. The boolean 'initialize
Hi Eric,
Thanks for the updates. I've pushed this changeset:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/97dc93591ae7
A few comments and minor corrections.
1. There was no changeset in the webrev; it was still just a plain patch.
Depending on how you ran webrev, you might have stumbled over a
Looks good.
Masayoshi
On 1/30/2014 5:31 AM, Aleksej Efimov wrote:
Masayoshi, Sean,
Thank you for the review and your comments.
I have prepared a second version of the fix [1] without the
.properties files. These files are used in
test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTe
Hi Stuart
Looks like in you new webrev. The wait will continue to go loop until
systemStub is not null. If it’s what you meant to do that?
Thank you
Tristan
On Jan 30, 2014, at 10:57 AM, Stuart Marks wrote:
> Hi all, wow, lots of comments on this. Let me see if I can tackle them in one
> mes
This simpler form, with the interruption logic corrected, seems fine to me.
David
On 30/01/2014 12:57 PM, Stuart Marks wrote:
Hi all, wow, lots of comments on this. Let me see if I can tackle them
in one message.
Quick aside before I get to the issues: my priorities for this code are
correctne
Hi all, wow, lots of comments on this. Let me see if I can tackle them in one
message.
Quick aside before I get to the issues: my priorities for this code are
correctness and maintainability, possibly at the expense of performance. In
other words I'm willing to make the code more complex so th
On 1/24/2014 1:33 AM, Alan Bateman wrote:
On 23/01/2014 22:55, Miroslaw Niemiec wrote:
Hello!
This is a simple backport from 8 to 7.
Looking for a review of this even though it only requires a testcase
change due to the use of lambda expressions.
Since this is the first of these I've encounter
Masayoshi, Sean,
Thank you for the review and your comments.
I have prepared a second version of the fix [1] without the .properties
files. These files are used in
test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java
test and because of that this test was removed also.
Thank
The java.security-aix file looks fine to me.
--Sean
On 01/29/2014 12:59 PM, Volker Simonis wrote:
Hi,
please review the following small change:
http://cr.openjdk.java.net/~simonis/webrevs/8033154/
which fixes the AIX build after the integration of
ppc-aix-port/stage-9/jdk to jdk9/dev/jdk.
I
On 29/01/2014 17:59, Volker Simonis wrote:
Hi,
please review the following small change:
http://cr.openjdk.java.net/~simonis/webrevs/8033154/
which fixes the AIX build after the integration of
ppc-aix-port/stage-9/jdk to jdk9/dev/jdk.
I would ideally like to push this change to jdk9/hs-comp/j
On 1/29/2014 5:09 AM, Peter Levart wrote:
Since I don't know what should be the correct behaviour of javac, I
can leave the Reference.java changes as proposed since it compiles in
both cases. Or should I revert the change to declaration of local
variable 'q' ?
I slightly prefer to revert
On 1/29/14 9:59 AM, Volker Simonis wrote:
Hi,
please review the following small change:
http://cr.openjdk.java.net/~simonis/webrevs/8033154/
which fixes the AIX build after the integration of
ppc-aix-port/stage-9/jdk to jdk9/dev/jdk.
I would ideally like to push this change to jdk9/hs-comp/jd
Hi,
please review the following small change:
http://cr.openjdk.java.net/~simonis/webrevs/8033154/
which fixes the AIX build after the integration of
ppc-aix-port/stage-9/jdk to jdk9/dev/jdk.
I would ideally like to push this change to jdk9/hs-comp/jdk because
that's the only repository where t
On 01/28/2014 04:46 PM, Alan Bateman wrote:
On 28/01/2014 08:44, Peter Levart wrote:
Yes, I tried that too and it results in even more unsafe casts.
It's odd yes, since the compile-time error is not present when
building via OpenJDK build system make files (using "make images" in
top directo
Hi Stuart,
My eye was caught by the following new method:
328 private synchronized void awaitInitialized() {
329 try {
330 while (!initialized) {
331 wait();
332 }
333 } catch (InterruptedException ie) {
3
On Jan 29, 2014, at 10:29 AM, Alan Bateman wrote:
> I just wonder if you could change initialized to volatile and only
> synchronize/wait when false? That way you would only be adding a read of a
> volatile. I assume the stub can never be null so maybe it could be changed to
> volatile and on
On 29/01/2014 06:51, Stuart Marks wrote:
Hi all,
Please review this fix to a race condition in rmid initialization.
Briefly, rmid subclasses the RMI registry implementation and provides
special handling for its own stub. Unfortunately the registry is
exported in the super() call, making remot
Hi Stuart,
This looks fine to me.
Tristan: the initialized field is only accessed under synchronization so
does not need to be volatile.
Cheers,
David
On 29/01/2014 4:51 PM, Stuart Marks wrote:
Hi all,
Please review this fix to a race condition in rmid initialization.
Briefly, rmid subclas
19 matches
Mail list logo
