[webkit-gtk] Sockets/file descriptors and the web extension

[Michael Catanzaro]

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 
<aperez at 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.)

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.

> 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.

Michael