Aleksa Sarai <cyphar@xxxxxxxxxx> writes: > On 2020-07-27, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> To the best of my knowledge processes with more than one thread >> calling exec are not common, and as all of the threads will be killed >> by exec there does not appear to be any useful work a thread can >> reliably do during exec. > > Every Go program which calls exec (this includes runc, Docker, LXD, > Kubernetes, et al) fills the niche of "multi-threaded program that calls > exec" -- all Go programs are multi-threaded and there's no way of > disabling this. This will most likely cause pretty bad performance > regression for basically all container workloads. So it is a good point that container runtimes use Go, and that fundamentally anything that uses Go will be multi-threaded. Having just looked closely at this I don't think in practice this is an issue even at this early state of my code. If those other threads are sleeping the code I have implemented should be a no-op. If those threads aren't sleeping you have undefined behavior, as at some point the kernel will come through and kill those threads. Further unless I am completely mistaken the container runtimes use forkAndExecInChild from go/src/syscall/exec_linux.go which performs a vfork before performing the exec. Eric
