On 12/5/18 3:28 PM, Michael Catanzaro wrote:
WebKit uses several child processes. A WebKitWebExtension is just a way
to run code in the WebKitWebProcess. Each WebKitWebView corresponds to
one WebKitNetworkProcess and one or more WebKitWebProcess processes.
These will be created regardless of whether or not you use the
WebKitWebExtension class to inject code into the WebKitWebProcess
processes.
On Wed, Dec 5, 2018 at 1:51 PM, Adrian Perez de Castro
<ape...@igalia.com> wrote:
Are you setting the close-on-exec flag [1] on the file descriptor? If
not,
it may be as well that the file descriptor for the socket is being
inherited
by the child processes (WebKitNetworProcess, WebKitWebProcess, etc).
This should not be possible. WebKit creates subprocesses using
g_spawn_async() in ProcessLauncherGLib.cpp. You can review the relevant
code in GLib's gspawn.c. After forking, GLib iterates through all open
file descriptors (except stdin, stdout, and stderr) and sets FD_CLOEXEC
on each one to ensure they get closed when it later calls exec.
Otherwise, if Eclipse failed to set CLOEXEC itself, then the file
descriptors would be leaked in the child process, and you would probably
wind up with this socket in use or not available error. (This behavior
can be disabled using the G_SPAWN_LEAVE_DESCRIPTORS_OPEN flag, but
WebKit does not use this flag.)
This is very useful thank you, I am going to look into the closing of
the port/socket a bit more closely as I am starting to suspect the issue
lies there and not with WebKit.
So Eric, you say "debugging shows that the web extension still holds
onto the socket/file descriptor." Are you sure the affected file
descriptor is really owned by the WebKitWebProcess? If so, something
very weird is happening inside gspawn.c, because it shouldn't be possible.
This is what was provided to me by the end user, and it's observed that
the bug is reproducible in certain steps, only when a web extension is
created. However this again could be related to the closing of the
port/socket and not a WebKit issue. I'll look into it further.
On a different note, from the brief description if the use case you
gave on
your first e-mail, I think you can probably get things done without using
a WebKitWebExtension at all.
Yes, if it's possible to avoid the need for a WebKitWebExtension
altogether, that would be ideal.
I did not write the WebKit implementation for SWT, but IIRC the reasons
for using an extension are:
1) We have API that allows users to define JS functions which will (when
executed) return values back to SWT at the Java level. We accomplish by
creating an extension, registering a function, and communicating with
the main SWT Java process via DBus.
2) These functions need to be available all the time, meaning they need
to be re-registered whenever a page is refreshed. This means listening
to the "window-object-cleared" signal, and re-registering the JS
functions on page refresh.
3) There is also API which allows an SWT client to execute JS
synchronously which is a bit tricky as webkit_web_view_run_javascript()
is async. My colleague who implemented WebKit in SWT managed to
workaround this by using a web extension and DBus.
Anyway thank you for your help on such a vague kind of question, I'm
going to investigate the matter further with the bug reporter.
Eric
_______________________________________________
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk
