[Webkit-unassigned] [Bug 222366] [WPE][GTK] Reconsider moving network session APIs to WebKitWebsiteDataManager

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #10)
> Comment on attachment 464556 [details]
> WIP patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=464556&action=review
> 
> I looked over the first half of the patch so far. My opinion is: very good.
> 

Great, thanks!

> > Source/WebKit/UIProcess/API/glib/WebKitNetworkSession.cpp:536
> > +void webkit_network_session_set_memory_pressure_settings(WebKitMemoryPressureSettings* settings)
> > +{
> > +    std::optional<MemoryPressureHandler::Configuration> config = settings ? std::make_optional(webkitMemoryPressureSettingsGetMemoryPressureHandlerConfiguration(settings)) : std::nullopt;
> > +    WebProcessPool::setNetworkProcessMemoryPressureHandlerConfiguration(config);
> > +}
> 
> This one looks weird. Probably a preexisting issue, but I don't like that
> the setting works globally instead of on a particular
> WebProcessPool/WebKitWebContext or WebKitNetworkSession.
> 

That's because we want to apply the settings to any network process spawned by the website data store. Now there's only one network process, but still, you can't set different settings per network session, because it's global to the network process. So, this is like a static method of WebKitNetworkSession.

> > Source/WebKit/UIProcess/API/glib/WebKitNetworkSession.h.in:61
> > +struct _WebKitNetworkSession {
> > +    GObject parent;
> > +
> > +    /*< private >*/
> > +    WebKitNetworkSessionPrivate *priv;
> > +};
> > +
> > +struct _WebKitNetworkSessionClass {
> > +    GObjectClass parent_class;
> > +
> > +    /*< private >*/
> > +    void (*_webkit_reserved0) (void);
> > +    void (*_webkit_reserved1) (void);
> > +    void (*_webkit_reserved2) (void);
> > +    void (*_webkit_reserved3) (void);
> > +};
> 
> This might depend on how exactly Adrian decides to handle bug #243663, but I
> think it's time to start using G_DECLARE_FINAL_TYPE. Then we would have the
> instance struct in the source file instead of the header (after all,
> everything there is private), and the class struct would be hidden behind
> the marco. We wouldn't maintain vtable padding unless we make it derivable
> in the future (which for this class we'd never do).
> 
> Let's talk to Adrian and see what he's planning.

I guess the tricky part is that we use the new placement syntax for the private struct to be able to use smart pointers, that's why we have our own macros to define types. G_DECLARE_FINAL_TYPE doesn't use a private struct, I think.

-- 
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/20230120/982dcf3a/attachment.htm>