The original reason for that is purely technical - it is required to call unshare(CLONE_NEWUSER) in the main thread of a program. Since cachepot-dist is multi-threaded and the build is executed on a new thread, we used a hack in which we fork() and call unshare in the forked child (fork() forks the calling thread into a main thread of a forked child process).
Using fork carries a lot of subtle details we need to be aware of; the current implementation uses some async-signal-unsafe syscalls, which IIUC can hand our process in a signal handler - not ideal!
An initial idea is to provide yet another entrypoint (think cachepot-dist sandbox) to the binary that handles the sandbox setup and runs the actual build; we will have full control and can call everything on the main thread of a program.
Introduced in #128.
The original reason for that is purely technical - it is required to call
unshare(CLONE_NEWUSER)in the main thread of a program. Sincecachepot-distis multi-threaded and the build is executed on a new thread, we used a hack in which wefork()and callunsharein the forked child (fork()forks the calling thread into a main thread of a forked child process).Using
forkcarries a lot of subtle details we need to be aware of; the current implementation uses some async-signal-unsafe syscalls, which IIUC can hand our process in a signal handler - not ideal!An initial idea is to provide yet another entrypoint (think
cachepot-dist sandbox) to the binary that handles the sandbox setup and runs the actual build; we will have full control and can call everything on the main thread of a program.