<AWT Dev> [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper

[Anthony Petrov]

Hi Leonid,

>  93     NSApplicationAWT* theApp = (NSApplicationAWT*)[NSApplication sharedApplication];    

Actually, in case an SWT application is running, this conversion may not 
work as expected. Should we possibly perform an isKindOfClass check, and 
if it's not our application class, use the previous approach (i.e. spin 
a single empty block through the event loop)?

Otherwise the fix looks fine.

--
best regards,
Anthony

On 6/15/2012 9:06 PM, Leonid Romanov wrote:
> Hi,
> I've adressed your comments 
> in http://cr.openjdk.java.net/~leonidr/7124239/webrev.01/
> More specifically: 
> 1. Removed )
> 2. After some consideration I've decided to use timestamp in order to 
> distinguish our event from others: seems like it's the most bulletproof 
> method. 
> 3. You could be right. I've replaced the loop with NSConditionLock 
> machinery.   
> 
> On 14.06.2012, at 19:12, Anthony Petrov wrote:
> 
>> Hi Leonid,
>>
>> 1. In NSApplicationAWT: the NSLog("Here...") statements. I use such 
>> debugging output, too! :) However, for production code please either 
>> replace them with meaningful messages, or remove them altogether.
>>
>> 2.
>>> 344 - (void)sendEvent:(NSEvent *)event
>>
>> I'm afraid that using the NSApplicationDefined and just skipping it 
>> may conflict with other native toolkits, such as SWT, or some custom 
>> native libraries. I think we should let such events go through the 
>> [super sendEvent].
>>
>> 3. Isn't the loop in LWCToolkit.m too tight? There's an issue with 
>> performSelector on the Mac in that selectors are processed strictly 
>> before processing events. If the queue is flooded with posted 
>> selectors, the event may never have a chance to be handled.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 06/14/12 08:25, Leonid Romanov wrote:
>>> Hi,
>>> Please review a fix for 7124239: [macosx] 
>>> sun.awt.SunToolkit.InfiniteLoop exception in realSync called from 
>>> SwingTestHelper.
>>> The problem is that syncNativeQueue() doesn't fully sync the native 
>>> queue. For example, if there are, say, 25 events in the native queue 
>>> waiting to be processed, nativeSyncQueue might return after only one 
>>> event has been processed. realSync() calls syncNativeQueue() in a 
>>> loop until nativeSyncQueue() reports that no native events have been 
>>> processed as the result of the call or the maximum number of 
>>> iterations (which is 20) has been exceeded (which leads to the 
>>> exception). And since there are more than 20 events in the native 
>>> queue, we get the exception.
>>>
>>> Bug:  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124239
>>> Webrev: http://cr.openjdk.java.net/~leonidr/7124239/webrev.00/
>>>
>>> Thanks,
>>> Leonid.
>