-
Notifications
You must be signed in to change notification settings - Fork 1.6k
REGRESSION(281488@main): [WPE][GTK] Process launching is slow #33270
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
REGRESSION(281488@main): [WPE][GTK] Process launching is slow #33270
Conversation
EWS run on previous version of this PR (hash 68a3b45)
|
68a3b45
to
7ac3294
Compare
EWS run on previous version of this PR (hash 7ac3294)
|
7ac3294
to
77d5936
Compare
EWS run on previous version of this PR (hash 77d5936)
|
77d5936
to
f210f5e
Compare
EWS run on previous version of this PR (hash f210f5e) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice that we can make process launching fully async. Probably it would have been good to have even before the recent change to pass real PIDs to the launcher—better late than never!
I'm not sure that it's actually fully async. It's using |
f210f5e
to
d95ef65
Compare
EWS run on previous version of this PR (hash d95ef65) |
d95ef65
to
5768449
Compare
EWS run on current version of this PR (hash 5768449) |
https://bugs.webkit.org/show_bug.cgi?id=279026 Reviewed by Carlos Garcia Campos and Adrian Perez de Castro. ProcessLauncher is already designed to support asynchronous process launching, but the GLib implementation ignores this and does everything synchronously. Previously this was OK because ProcessLauncher::launchProcess would return immediately after the subprocess is spawned, without waiting for any code to execute in the subprocess. Apparently that's fast enough in practice. But after my changes in 281488@main, we now additionally wait for the subprocess to send credentials to the parent via a socket. That turns out to be drastically slower than actually spawning the process. The blocking is unnecessary because the code was already carefully structured to allow asynchronicity. I just failed to take advantage of it. Instead, return immediately after spawning the subprocess. Then, wait until the socket is ready before reading the pid from it. Now the read can complete instantaneously instead of blocking the UI process. * Source/WebKit/UIProcess/Launcher/ProcessLauncher.h: * Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp: (WebKit::ProcessLauncher::launchProcess): Canonical link: https://commits.webkit.org/283414@main
5768449
to
cf8f5f5
Compare
Committed 283414@main (cf8f5f5): https://commits.webkit.org/283414@main Reviewed commits have been landed. Closing PR #33270 and removing active labels. |
cf8f5f5
5768449
🧪 wpe-wk2🧪 ios-wk2🧪 ios-wk2-wpt🧪 api-ios🧪 mac-AS-debug-wk2🧪 gtk-wk2🧪 mac-intel-wk2