On 12/24/13 11:57 AM, Petr Pchelko wrote:
Hello, Sergey.
As I remember doAWTRunLoop process events and selectors in case of drags/DnD
otherwise how we got mouse events? Or I have missed something?
In case of DnD we have several nested loops in place:
1. The native Cocoa DnD nested loop. It's started within the NSView
dragImage:... call. It processes only the DnD-related events - some mouse
events, some key events and flag changed events. This is for the DragSource.
And we cannot emulate such event in postDummyevent?
2. To dispatch some DropTarget events on EDT synchronously we start our own
nested loop in doAWTRunLoop using the ToolkitThreadBlockedHandler. In this case
we do process the events in a nested runLoop.
This case might actually be a bug, because we are short-circuiting normal event
processing and could "steal" some events from Cocoa. But I would not address
this it in this fix.
Probably it is a good time to realize how it should work? Since the fix
adds complexity which can not be necessary in the future.
Without the DnD we use a doAWTRunLoop which does not process events. (Except
the case with Single-Threaded Interop with FX).
Actually, after some more thinking I believe I should reimplement the fix and
follow Anthony's suggestion with a timeout, because my fix is too complex. I'll
send a new webrev later today.
With best regards. Petr.
On 24.12.2013, at 1:41, Sergey Bylokhov <[email protected]> wrote:
Hi, Petr.
On 23.12.2013 16:54, Petr Pchelko wrote:
The problem:
nativeSyncQueue synchronizes the native event queue. However, there are several
situations when a dummy event posted to the native queue is not dispatched.
These are our own nested loop in doAWTRunLoop and Cocoa's internal nested loop
in NSView:dragImage.
As I remember doAWTRunLoop process events and selectors in case of drags/DnD
otherwise how we got mouse events? Or I have missed something?
Solution:
1. The interruptNativeSyncQueue was introduced. In case we are waiting for the
native event queue this method interrupts waiting, otherwise it's a no-op. This
is needed for the following reason: suppose the nativeSyncQueue is called on
EDT. While the queue is flushed some event was processed which caused us to
call doAWTRunLoop. As EDT is blocked we would have got a deadlock. Interrupting
the wait lets EDT flush it's events and lets AppKit exit a nested loop. When
the nativeSyncQueue is interrupted we do not immediately exit realSync, but
flush EDT and try to sync native queue again. Most likely in this case we would
not be in a nested loop and will successfully sync a native queue.
2. A lightweight version of nativeSyncQueue was introduced. This one does not
flush the event queue, it only flushes a selector queue. This is needed to not
deadlock when realSync was called during DnD. Suppose nativeSyncQueue is called
while the app is in the native nested dragging loop. Until dragging operation
finishes only dragging-related events will be processed. So we have no
opportunity to flush the queue as our dummy event will be blocked by a dragging
nested loop.
I've tested it by running almost all awt and swing tests. No new failures, some
tests start to pass after the fix.
With best regards. Petr.
--
Best regards, Sergey.
--
Best regards, Sergey.
