<AWT Dev> <Awt Dev> [9] Review Request for 8132664: closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on Windows

[Sergey Bylokhov]

On 04.08.15 14:54, Semyon Sadetsky wrote:
> On 8/3/2015 6:05 PM, Sergey Bylokhov wrote:
>> Hi, Semyon
>> Did you try to change dwMilliseconds from INFINITE to the timeout(10 
>> seconds by default?) which is passed to the method? It does not help? 
>> Because even when dnd is not used we should not wait event for 
>> infinite time.
> It would not help to fix the issue because 10 seconds is too big 
> interval. But for consistency it is not bad to have a time limit.
> http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.01/
Note that syncNativeQueue is intended to wait until the native event 
queue is flushed or until timeout will expire. So even if timeout is 
expired we collect the native events during this period of time.Can you 
double check that the event counter is incremented during dnd? I do not 
know how we block the toolkit thread, probably we create some nested 
loops which ignore our event posted from syncNativeQueue, can we change 
that?

The timeout value is maintained on the shared level and actually this 
test will fail with timeout on osx as well JDK-7185258. The test will 
fail even if the time out will be changed to ±100ms, because it call 
realsync on each pixel move, ±200 times. This problem can be fixed in 
different ways like tweak of timeouts and numbers of iterations, or 
changing the test to call w4idle only after the latest move(actually I 
think this method can be moved to the robot class).

So I still think that the right fix for a deadlock, which is subject of 
this bug, is simply change the syncNativeQueue and waits using a timeout 
if it is positive, and waits forever if timeout is negative (the same 
bug on osx JDK-8080504).
>
>>
>> On 03.08.15 17:26, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132664
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.00/
>>>
>>> DoDragDrop() is blocking, so upon drag operation is triggered the 
>>> toolkit thread is blocked and the WM_AWT_WAIT cannot be processed 
>>> which in its turn blocks the AWT robot.
>>> The solution is to escape AWT robot waiting in syncNativeQueue() if 
>>> drag operation is in progress.
>>>
>>> --Semyon
>>
>>
>


-- 
Best regards, Sergey.