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.
