Sergey, Phil
thanks for comments!
here is the updated version:
http://cr.openjdk.java.net/~anashaty/8080504/webrev.01/
<http://cr.openjdk.java.net/%7Eanashaty/8080504/webrev.01/>
Thanks!
Anton.
On 25.06.2015 0:56, Phil Race wrote:
On 06/24/2015 12:26 PM, Sergey Bylokhov wrote:
Hi, Anton.
- Why the timeout is used as an int?
I agree that seems wrong. The downcast from long to int
could even result in the int being "-1" .. which would be
the infinite timeout - although I am not sure who would
wait around to see the difference :-)
-phil.
- Will the fix conform to this statement in the documentation of
ST.realSync()?
@param timeout the maximum time to wait in milliseconds,*negative
means "forever"*.
But I am not sure that all our implementations works in case of
negative timeout.
On 23.06.15 20:31, Anton Nashatyrev wrote:
Hello,
could you please review the following fix:
fix: http://cr.openjdk.java.net/~anashaty/8080504/webrev.00/
<http://cr.openjdk.java.net/%7Eanashaty/8080504/webrev.00/>
bug: https://bugs.openjdk.java.net/browse/JDK-8080504
Problem: under MacOS X the realSync() may hang under some
circumstances.
Fix: make the Java_sun_lwawt_macosx_LWCToolkit_nativeSyncQueue
method respecting timeout argument
Thanks!
Anton.
--
Best regards, Sergey.
