On Tue, May 18 2021 at 07:08:21 AM +0200, linux...@tin.it wrote:
It doesn't matter where the callbacks are,
they are called synchronously and, when invoked, they run in the
<page>
thread, even if they were declared in what "seems" the <main> (or UI)
thread.
Hi,
(Beware: none of WebKitGTK's APIs are threadsafe. They can only be
used on the GTK thread, which is almost always your main thread.)
The concern isn't threads, it's process boundaries. IPC between
processes is fine, but synchronous IPC that blocks the entire web
process is not. Synchronous IPC between processes must be kept to a
bare minimum. It's should be possible to design a send-request API that
only blocks network loads in the web process, and does not the entire
web process, but I guess that's probably not how it works internally
today, so would likely need some work to make it happen. (I'm just
guessing: I haven't actually looked at the code.) This is one of those
"patches welcome" things I'm afraid, and changing it would probably be
a lot harder than writing your web process extension was. :)
Anyway, that
is gone. Now I am fighting with the find_controller which doesn't seem
to work, not even in the already-compiled MiniBrowser application that
I received bundled with the webkit2gtk library (libwebkit2gtk-4.0.so.
37.49.9 on a Debian stable). I will investigate more, but it seems
there is something wrong in the library itself.
Good luck!
Michael
_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
