[webkit-changes] [WebKit/WebKit] cf8f5f: REGRESSION(281488 at main): [WPE][GTK] Process launch...
Michael Catanzaro
noreply at github.com
Tue Sep 10 08:29:54 PDT 2024
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: cf8f5f540b30716eb35ed55b7ea1fc6ca78534c1
https://github.com/WebKit/WebKit/commit/cf8f5f540b30716eb35ed55b7ea1fc6ca78534c1
Author: Michael Catanzaro <mcatanzaro at redhat.com>
Date: 2024-09-10 (Tue, 10 Sep 2024)
Changed paths:
M Source/WebKit/UIProcess/Launcher/ProcessLauncher.h
M Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp
Log Message:
-----------
REGRESSION(281488 at main): [WPE][GTK] Process launching is slow
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 at 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
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list