Hi, Petr.
From the quick review:
- I suggest do not remove LWCToolkit.flushPendingEventsOnAppkit and
reuse it in CDropTargetContextPeer.flushEvents Is it possible?
- Can you please take a look to this
http://java.net/jira/browse/MACOSX_PORT-768 Looks like the workaround
from those issue is not necessary now.
- It would be really helpful to add additional doce about runloops.
- The test will be welcome, because this CR fix the possible deadlock,
when we use performOnMT inside DND .
- Synchronisation in CToolkitThreadBlockedHandler is not necessary?
- There are some changes related to VoiceOver could you please check
that it works?
- I'm not sure but looks like stopAWTRunLoop should stop runloop
synchronously since after that we release CFRelease(mediatorObject). Is
it possible that when we call endRunLoop the object will be released?
14.02.2013 10:58, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
http://bugs.sun.com/view_bug.do?bug_id=8006634
The fix is available at:
http://cr.openjdk.java.net/~pchelko/8006634/webrev.00/
This fix makes a lot of changes in nested event loops:
1. CToolkitThreadBlockedHandler was made a subclass of Mutex as it is made on
other platforms. Shared code relies on that with logic for entering/exiting
nested event loops. Previously it did not matter as
CToolkitThreadBlockedHandler did not make a actual nested loop. Now it makes a
native nested loop via doAWTRunLoop.
2. doAWTRunLoop method is changed
a. Now we have a boolean flag processEvents. If it is set to false, we
do not process native events while in the nested loop, same as how it was done
before the fix. If it is set to true, events are processed while in the loop.
Attention is needed when using this new feature, because we short-circuit
native event processing and there could be some cases when it breaks Appkit.
(resizing windows with a mouse could be an example) However we need this
feature in the Drag and Drop.
b. I have got rid of an feature to run the nested loop in
NSDefaultRunLoopMode, it was never used.
3. We decided that we are getting rid of the deadlock detection mechanism: it
is rarely used, nobody have ever seen the error message from it. I have tested
a lot without this feature and it looks like everything is fine, however I am
absolutely not sure about this decision. I am including Peter and Ragini as
Accessibility was using this functionality and I had to change Accessibility
code a bit.
4. Some native methods from the LWCToolkit were made package-private. The
comment stated that deploy used them, but I've cloned there code and they
apparently do not use it any more. Looks like the comment is from Apple times
and we do not event have a WebkitPluginObject any more.
With best regards. Petr.
--
Best regards, Sergey.
