[webkit-dev] Glib download API change request
Michael Catanzaro
mcatanzaro at redhat.com
Tue Feb 18 09:00:05 PST 2025
Hm, we'll need to investigate this.
Deprecating APIs is easy. Adding newer replacements is often easy. But
removing APIs is extremely disruptive; we don't want to do that unless
there is absolutely no viable alternative. It requires an API version
bump, which requires changes in every application that depends on
WebKitGTK/WPE even if they don't use the affected API, and new parallel
packaging in every downstream.
We should try to reimplement the sync APIs using the async APIs so we
don't have to remove them. The challenge here is we have to do that
*without* iterating the global RunLoop (otherwise, application
callbacks will be dispatched at unexpected times, and all manner of
bugs could occur, including memory corruption and other
vulnerabilities). So we need to do this using a "private" RunLoop. In
Linux-specific code, we would do this easily by using GMainContext
directly; we would create a new GMainContext, push it as
thread-default, iterate it until the async operation has completed, and
then pop it, thereby creating a synchronous wrapper around an async
function call. But I don't think it can be done without changes in
WebKit's RunLoop. RunLoop does not have any equivalent concept to allow
temporarily making a different RunLoop the "current" default RunLoop
for a thread, which is what we need here. It's probably doable, though.
Once before, sometime rather recently (maybe 6-12 months ago?), we gave
up on doing this properly and landed a patch that iterates the global
run loop behind the application's back in order to fix some bug. I
don't remember what particular bug it was, but I was opposed to doing
that; it's really not safe.
If you're OK with keeping the existing synchronous code around, it
would be less work to just maintain separate sync and async paths.
We'll remove all deprecated APIs in the far distant future, next time
we bump API version; we could add a comment to delete the sync versions
then.
Michael
More information about the webkit-dev
mailing list