Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux: 100% CPU when using external-message-pump or multi-threaded-message-loop #2809

Closed
magreenblatt opened this issue Nov 18, 2019 · 11 comments
Labels
bug Bug report Framework Related to framework code or APIs linux Linux platform

Comments

@magreenblatt
Copy link
Collaborator

Original report by Mathieu Lafon (Bitbucket: mlafon, GitHub: mlafon).


Since CEF 76 (3809), using external-message-pump or multi-threaded-message-loop on Linux causes a high CPU usage of the main process.

This is easily reproduced using cefclient on the latest CEF version (78.3.1+g8819d2e).

Based on my understanding, this seems to be related to https://chromium-review.googlesource.com/c/chromium/src/+/1594695. MessagePumpGlib::HandlePrepare() will always return a timeout equal to 0 because state_ is null, this was not the case in the previous version.

Using the standard loop (CefRunMessageLoop) is not always possible when we already have a message loop. Is there something that can be done for this issue?

@magreenblatt
Copy link
Collaborator Author

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).


Have you tried patching Chromium by reverting the changes from the mentioned commit?

@magreenblatt
Copy link
Collaborator Author

Original comment by Mathieu Lafon (Bitbucket: mlafon, GitHub: mlafon).


No, I have not tried to build a modified version. I am now using the standard loop (CefRunMessageLoop) and have made modifications to ensure that my other event loop is still called.

Regarding my initial comment, the high CPU usage of cefclient when using multi-threaded-message-loop is not related to this modification. It seems to be related to the idle callback (tests/cefclient/browser/main_message_loop_multithreaded_gtk.cc) which is permanently triggered.

@magreenblatt
Copy link
Collaborator Author

Original comment by Guillermo Zunino (Bitbucket: Guilllermo Zunino).


I’m facing the same issue, 100% CPU usage in linux with external_message_pump

@magreenblatt
Copy link
Collaborator Author

  • changed component from "Unclassified" to "Framework"

@magreenblatt
Copy link
Collaborator Author

The external-message-pump problem could be issue #2970.

@magreenblatt
Copy link
Collaborator Author

@magreenblatt
Copy link
Collaborator Author

Fix excessive CPU usage with external and multi-threaded message loops (fixes issue #2809, fixes issue #2970).

→ <<cset a3919cb0ec14 (bb)>>

@magreenblatt
Copy link
Collaborator Author

  • changed state from "new" to "resolved"

@magreenblatt
Copy link
Collaborator Author

Fix excessive CPU usage with external and multi-threaded message loops (fixes issue #2809, fixes issue #2970).

→ <<cset a49878faee8c (bb)>>

@magreenblatt
Copy link
Collaborator Author

Fix excessive CPU usage with external and multi-threaded message loops (fixes issue #2809, fixes issue #2970).

→ <<cset 744847039285 (bb)>>

@magreenblatt
Copy link
Collaborator Author

Original comment by Stephan Engelmann (Bitbucket: Stephan Engelmann).


We tested the fix using the CEF Automated build cef_binary_84.4.1+gfdc7504+chromium-84.0.4147.105_linux64.tar.bz2.

After building the test applications and starting the cefclient application with the external message pump flag one core is always using 100% CPU.

./cefclient --external-message-loop


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug report Framework Related to framework code or APIs linux Linux platform
Projects
None yet
Development

No branches or pull requests

1 participant