-
Notifications
You must be signed in to change notification settings - Fork 196
Open
Labels
Description
When setStandaloneMessageLoopEnabled = true, CefClient runs on the Cef UI thread instead of the app's main thread. QCefView switches to the app's main thread using /runInMainThread/runInMainThreadAndWait in some client callbacks, but this still doesn't solve the multithreading issue with CefRefPtr<CefBrowser>.
For example:
// 1. On app's main thread.
void QCefViewPrivate::browserGoForward() {
if (pCefBrowser_)
pCefBrowser_->GoForward(); // pCefBrowser_ is CefRefPtr<CefBrowser>
}
// 2. On Cef UI thread.
CCefClientDelegate::onAfterCreate(CefRefPtr<CefBrowser>& browser) {
// Accessing the browser.
}
// 3. Cef accesses `CefBrowser` internally on the Cef UI thread.
CefRefPtr<CefBrowser> browser;
// Accessing the browser.
cefClientDelegate->onAfterCreate(browser);
// Accessing the browser.QCefViewPrivate::browserGoForward accesses CefBrowser on the app's main thread. Cef's callbacks to CefClient's handler interfaces, such as onAfterCreate, or internal Cef access to CefBrowser also occur on the Cef UI thread. This still presents multithreading safety issues.
It seems that running Cef on a separate thread (Cef UI thread) doesn't offer a good solution.
Reactions are currently unavailable