Hi Alexander,

On 4/28/2012 12:16 PM, Alexander Zuev wrote:
the ToolkitThreadBlockerHandler is an interface that is supposed to be used when program has to wait for the event pushed to the EDT finish its task and
he calls like this:
            while (!dispatcher.isDone()) {
DataTransferer.getInstance().getToolkitThreadBlockedHandler().enter();
            }
and the event handler in its unregisterEvent() method calls for handler.exit() The method is supposed to make sure that waiting on the EDT doesn't create deadlocks. The implementation depends on the toolkit architecture - on some toolkits it's NoOp since they don't care if EDT is waiting, but in LWCToolkit our AWT components are backed by Swing delegates so there are a lot of calls from native application thread to EDT and vice versa so we can't afford to stop both threads. Solution is the code that makes secondary AppKit event loop to handle native events so waiting on EDT will leave at least one event loop pumping.

Thanks!

The name is correct because despite the fact that we are in AWT code (LWCToolkit) we don't create nested EDT loop but running nested native (AppKit) loop - hence the name: enter/exitNativeEventLoop()

Since the main event loop is already spinning, I would still suggest to rename it to, say, enter/exitNestedNativeEventLoop() to stress that this event loop is going to be an inner loop, rather than the main (outer) event loop.

--
best regards,
Anthony


With best regards,
Alex

On 4/27/12 20:54, Anthony Petrov wrote:
Hi Alexander,

Could you provide some details about the ToolkitThreadBlockedHandler interface? How is it used by the DnD code?

Also, I suggest to replace the word Native with Nested in enter/exitNativeEventLoop() method names.

--
best regards,
Anthony

On 4/26/2012 7:54 PM, Alexander Zuev wrote:
Hello,

please review my fix for the CR 7148289: [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame

Bug description is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7148289

Fix can be found at http://cr.openjdk.java.net/~kizune/7148289/webrev.00

With best regards,
Alex

Reply via email to