Now that render_worker_jail tracks workers, the apis are simplified such
that
- render_worker_create forks a subprocess
- render_worker_destroy kills a subprocess
- render_worker_jail_reap_workers reaps all exited subprocesses
Also add render_worker_jail_detach_workers that can be called by a
forked subprocess to "detach" (free without killing/reaping) workers.
v2: replace some checks for worker->{destroyed,reaped} by asserts (Ryan)
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1)
Reviewed-by: Ryan Neph <ryanneph@google.com> (v1)
Add render_client_detach_all_records to "detach" context records from
the child process before returning from render_client_create_context.
"Detaching" means destroying records without killing nor reaping the
workers.
This makes it clearer how context records are destroyed in subprocesses.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Pre-init virglrenderer only when tracing is disabled, otherwise perfetto
might get confused. Do a vkEnumerateInstanceExtensionProperties to
preload Vulkan ICDs.
"time for i in `seq 100`; do vulkaninfo > /dev/null; done" goes from
0m5.895s to 0m5.535s.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
The render server is a daemon that sits idle waiting for commands. When
requested to create a context, it forks and creates the context in a
subprocess. This isolates contexts from each other, from the server
process, and from the client process.
Because a context process can execute untrusted commands and depends on
GPU drivers, the isolation should improve the security.
There is also a multi-thread mode where each context is executed by a
thread. This mode is used to ease debugging, but maybe someone will
find a use case for it.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>