[Webkit-unassigned] [Bug 264036] New: [WPE][GTK] MemoryPressureMonitor should depend on GLowMemoryMonitor

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=264036

            Bug ID: 264036
           Summary: [WPE][GTK] MemoryPressureMonitor should depend on
                    GLowMemoryMonitor
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at redhat.com
                CC: bugs-noreply at webkitgtk.org

Currently we have a handrolled MemoryPressureMonitor used only by the Linux ports WPE and GTK. Both ports already depend on GLib, which has its own GMemoryMonitor. We might as well depend on logic that is already available to us. Benefits:

 * The current code attempts to access /sys/fs/cgroup, but this will almost always fail because bubblewrap sandbox is now mandatory if not running inside flatpak, and this location is not accessible in either or bubblewrap and flatpak sandboxes
 * GMemoryMonitor has various backends including one that uses xdg-desktop-portal, escaping the above limitation
 * It can become smarter in the future without requiring changes in WebKit. E.g. there is a plan to switch from depending on low-memory-monitor to depending on systemd in https://gitlab.gnome.org/GNOME/glib/-/issues/2931
 * It's used by lots of applications rather than WebKit alone, and we don't have to maintain it

The downside is the GMemoryMonitor API currently does nothing if low-memory-monitor is not running. This should be available on all desktops nowadays, but might be missing on embedded devices. Having a fallback to our existing MemoryPressureMonitor wouldn't hurt. But this problem would also go away if GMemoryMonitor were to use systemd instead.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20231101/23ef46d9/attachment-0001.htm>