Closed GoogleCodeExporter closed 8 years ago
What is the current relationship between the |context| Thread created in
CefApp.java and the AWT-EventQueue thread used for drag&drop? Will they always
be the same thread? Do they need to be the same thread? Is there some way that
we could force them to be different threads?
If we can't control which threads Java is using then I think it's OK to proceed
with the multi-threaded-message-loop approach. The notification_registrar
thread check failure is
https://code.google.com/p/chromiumembedded/issues/detail?id=755. It's a debug
assertion so shouldn't cause problems with a release build of libcef.
Original comment by magreenb...@gmail.com
on 18 Sep 2014 at 3:36
@#1: The notification_registrar thread check failure is now fixed in CEF.
Original comment by magreenb...@gmail.com
on 18 Sep 2014 at 8:41
@#1:
The main job of the context thread is to call the native CefDoMessageLoopWork()
approx. every 33ms and to keep an eye on shutdown requests. Due the
initialization of CEF is done on the AWT-EventQueue thread, we have to run the
message loop on the EventQueue as well.
For that reason an implementation of the interface Runnable is created and
passed to the AWT-EventQueue by calling "SwingUtilities.invokeLater(...)" which
in fact doesn't block the "context" thread. If the runnable is triggered on the
AWT-EventQueue thread, it calls N_DoMessageLoopWork() and returns. After that
the next event is handled by the EventQueue thread.
If you drag an item within the same application and drag over (touching the
browser UI is enough) the CEF based UI a native "DRAG START" Event will be
fired to the native CEF (chromium) implementation. This event will be handled
within the CEF message queue, which means in fact that it will be handled
within the AWT-EventQueue (the next time N_DoMessageLoopWork() is called).
CEF / chromium wants to collect some data about the drag item and therefore it
"asks" the OS about it. The OS itself asks the application the drag came from
and that's in fact the Java code running in the JVM.
Now my guessing starts:
Th OS sends and WindowsEvent to the Java code and I think the handling of this
WindowsEvents is running in the AWT-EventQueue.
So for that reason the calling OS-thread waits for a reply from the
AWT-EventQueue. But this reply will never be delivered because
N_DoMessageLoopWork() is waiting for a reply from the OS-thread and in fact the
N_DoMessageLoopWork() is currently executed on the AWT-EventQueue....Deadlock!
Changing the behavior of the JVM/JRE isn't possible. So we can' say that the
Event for "give me the drag data" has to be performed on another thread because
of Swing's architecture.
So I don't see any other solution than proceeding with the
multi-threaded-message-loop approach.
@#2: Thanks for your fix. I'll try CEF 3.1916.1839 within the next days.
Regards,
Kai
Original comment by k...@censhare.de
on 19 Sep 2014 at 5:45
@#3: Will the thread deadlock be an issue on OS X? If not, what do you think
explains the difference on that platform?
Do you have a final patch for the multi-threaded-message-loop usage on Windows?
Original comment by magreenb...@gmail.com
on 29 Sep 2014 at 4:50
@#4: The deadlock isn't an issue on OS X because we don't run the CEF message
loop within the AWT Dispatcher thread. It is handled within the "MainThread" of
the application by using performSelectorOnMainThread().
With the patch the windows and mac implementations are somewhat more similar in
the meaning of how the message loop is handled.
Attached you'll find a final patch for this issue. There some additional
changes compared to the first patch.
Regards,
Kai
Original comment by k...@censhare.de
on 2 Oct 2014 at 11:42
Attachments:
Here's a slightly different test case.
1. Open tests.details.MainFrame
2. Go to this URL:
http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_file
3. Click on "Choose file" on right pane
4. A file picker comes up. Make sure an image file e.g. a png image is visible
in the list of files displayed in the picker.
5. From within the file picker's list, drag the image file from picker to
browser's window.
6. Freeze similar to discussed in this defect.
In this case, there's no dragged item from Swing.
Original comment by christop...@gmail.com
on 3 Oct 2014 at 8:26
Verified that slightly different test case is also fixed with the patch
discussed here
Original comment by christop...@gmail.com
on 6 Oct 2014 at 5:26
@#5: Thanks, added in revision 106 with minor changes:
- Use anonymous namespace instead of static functions.
- Rename critical_wait_unix.cpp to critical_wait_posix.cpp for consistency.
Original comment by magreenb...@gmail.com
on 24 Oct 2014 at 4:02
Original issue reported on code.google.com by
k...@censhare.de
on 15 Sep 2014 at 6:18Attachments: