[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-awt-dev
Subject:    <AWT Dev> [7u6] Review request for 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in re
From:       artem.ananiev () oracle ! com (Artem Ananiev)
Date:       2012-06-21 10:22:44
Message-ID: 4FE2F5F4.8010902 () oracle ! com
[Download RAW message or body]


Looks fine.

Thanks,

Artem

On 6/19/2012 8:41 PM, Leonid Romanov wrote:
> Sounds like a good idea. Done:
> http://cr.openjdk.java.net/~leonidr/7124239/webrev.02/
>
> On 15.06.2012, at 23:02, Anthony Petrov wrote:
>
>> 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.
>

[prev in list] [next in list] [prev in thread] [next in thread]