Let ProcessManager own hard process termination. Callers can now
schedule a forced exit after graceful shutdown is requested. The request
is canceled automatically when the process monitor observes exit.
The compositor is moving into a dedicated helper process. That requires
a process to launch, channels for Browser and WebContent to talk to it
over, and client proxies on each side. Land all of that as an inert
scaffold first, gated behind --enable-compositor-process, so the default
rendering path is unchanged and later commits can fill in the protocol,
the service-side state, and the runtime switch against a stable target.
Exit WebContent immediately when either browser-side IPC peer
disconnects. Plumb Unix process exit status through LibWebView so the
browser process can tell clean owner-driven shutdown apart from renderer
crashes.
This keeps nonzero exits and signal deaths reported as crashes, while
letting status 0 exits disappear without making test-web report the page
as crashed.
There is no direct equivalent to SIGCHILD on Windows. The closest we
can get is monitoring a specific process, given a known pid. On Unix
there is no single solution to be able to do that in LibCore's
EventLoopImplementationUnix. For Linux there's a SYS_pidfd_open syscall
that can integrate into poll(), but on macOS a kqueue would be needed.
Given macOS uses EventLoopImplementationUnix for the headless view
implementation, we currently can't create a fully cross-platform
abstaction at the Event Loop level to match what Windows needs to do.
ProcessMonitor's purpose is to abstract away the Unix vs Windows
behaviour avoiding more inlined ifdef soup in ProcessManager.
When a child process exits, the SIGCHLD handler was destroying the
Process object synchronously within the signal dispatch context. This
triggered Process::~Process() which called m_connection->shutdown(),
attempting to join the IPC IO thread.
Joining threads from within signal handler context can cause deadlocks,
as observed when WebContent crashes during test-web runs.
Fix this by deferring the on_process_exited callback using
Core::deferred_invoke(), ensuring the Process destruction happens in
normal event loop context.
The intent is that this will replace the separate Task Manager window.
This will allow us to more easily add features such as actual process
management, better rendering of the process table, etc. Included in this
page is the ability to sort table rows.
This also lays the ground work for more internal `about` pages, such as
about:config.
