克隆与fork+unshare的差异

Question

不知何故，调用fork和unshare更容易，因为许多参数都是通过fork复制的，否则会手动包装到clone。我的问题是，(1)调用clone (在单独的名称空间中分叉一个新进程)和(2) fork+unshare (分叉一个新进程，然后留下父进程的名称空间)之间有什么区别。假设传递给clone和unshare的所有命名空间标志都是相同的。

auto flag = CLONE_NEWUSER | CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET | SIGCHLD;

因此，使用叉子，可以很容易地重用从父母那里继承的数据。

int mydata;  // this could be even more complicated, class, struct, etc.
auto pid = fork();
if(pid == 0) {
  // reuse inherited data in a copy-on-write manner
  unshare(flag);
}

对于克隆，我们有时必须将数据包装到另一个结构中，并将其作为void*传递给clone系统调用。

int mydata;
clone(func, stack+stack_size, flag, &wrapper_of_data);

在我看来，在上面的例子中，唯一的区别是性能上的问题，在这里叉子可能会更贵一些。但是，fork的特性为我节省了很多精力，因为它们都可以在新的命名空间中创建一个进程。

Answer 1

不知怎么的，它更容易调用叉子，然后取消共享，因为很多参数都是通过叉子复制的，否则会被手工包装来克隆。

这只适用于libc包装器函数。

底层系统调用更像fork()，在这种情况下可能会更好地工作：

long flags = CLONE_NEWUSER | ... | SIGCHLD;
long pid = syscall(__NR_clone, flags, 0, 0, 0, 0);

if(pid == 0) {
    /* child with unshared namespaces */
}

自从介绍克隆syscall以来，fork()只是针对所有其他参数的带有flags=SIGCHLD和0的克隆的一种特殊情况。

与只传递相同的标志克隆相比，可能没有理由更倾向于使用叉/unshare对。