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

[Semyon Sadetsky]

On 9/27/2016 7:09 PM, Sergey Bylokhov wrote:

> 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/
>
> Looks fine. Please file separate issue that syncNativeQueue() should 
> check that dnd callbacks are started/completed, because 
> "(newEventNumber - eventNumber) > 2" check is useless if we are in the 
> DND. And if some callbacks are in progress syncNativeQueue() should 
> notify the java side that we should call syncNativeQueue() one more time.
I have modified the fix to take the above into account. The updated 
webev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.02/
>
>>
>>>
>>> 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
>>>
>>>
>>
>
>