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:
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.
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:
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.