为什么多个克隆系统调用需要一个独立的go子程序？

本篇文章给大家分享《为什么多个克隆系统调用需要一个独立的go子程序？》，覆盖了Golang的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

我创建了小示例程序来检查子例程系统调用。

package main

func print() {
}

func main() {
    go print()
}

go子例程的痕迹

clone(child_stack=0xc000044000, flags=clone_vm|clone_fs|clone_files|clone_sighand|clone_thread|clone_sysvsem) = 27010
clone(child_stack=0xc000046000, flags=clone_vm|clone_fs|clone_files|clone_sighand|clone_thread|clone_sysvsem) = 27011
clone(child_stack=0xc000040000, flags=clone_vm|clone_fs|clone_files|clone_sighand|clone_thread|clone_sysvsem) = 27012
futex(0x4c24a8, futex_wait_private, 0, null) = 0
futex(0xc000034848, futex_wake_private, 1) = 1
exit_group(0)                           = ?

据观察，单个子例程调用了 3 次克隆系统调用，但堆栈大小如 go 所声称的那样小。您能否告诉我为什么三个克隆系统调用调用单个子例程。

以类似的方式在创建 pthread 时调用单次克隆系统调用。但堆栈大小很大。

#include 
#include 
#include  //header file for sleep(). man 3 sleep for details.
#include 

void *mythreadfun(void *vargp)
{
        return null;
}

int main()
{
        pthread_t thread_id;
        pthread_create(&thread_id, null, mythreadfun, null);
        pthread_join(thread_id, null);
        exit(0);
}

pthread 痕迹

clone(child_stack=0x7fb49d960ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARET_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fb49d9619d0, tls=0x7fb49d961700, child_tidptr=0x7fb49d9619d0) = 27370
futex(0x7fb49d9619d0, FUTEX_WAIT, 27370, NULL) = -1 EAGAIN (Resource temporarily unavailable)
exit_group(0) = ?

为什么多个克隆系统调用需要单个 go 子例程？因为在程序中只创建了单个子程序，就像第二个c语言程序中的单个pthread一样。另外两个克隆人叫什么目的？

解决方案

运行这个无操作程序：

package main

func main() {
}

跟踪克隆调用显示相同的三个 clone 调用：

$ go build nop.go
$ strace -e trace=clone ./nop
clone(child_stack=0xc000060000, flags=clone_vm|clone_fs|clone_files|clone_sighand|clone_thread|clone_sysvsem) = 12602
clone(child_stack=0xc000062000, flags=clone_vm|clone_fs|clone_files|clone_sighand|clone_thread|clone_sysvsem) = 12603
clone(child_stack=0xc00005c000, flags=clone_vm|clone_fs|clone_files|clone_sighand|clone_thread|clone_sysvsem) = 12605
 exited with 0

所以你在这里展示的是 go 能够创建一个没有克隆调用的 goroutine：

$ cat oneproc.go
package main

func dummy() {
}

func main() {
    go dummy()
}
$ go build oneproc.go
$ strace -e trace=clone ./oneproc
clone(child_stack=0xc000060000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 13090
clone(child_stack=0xc000062000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 13091
clone(child_stack=0xc00005c000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 13092
 exited with 0

（这并不奇怪——goroutines 不是线程）。

go 运行时（go 1.11/12 左右）

您要求提供更多详细信息 in comments。当前系统有一个 design document（如果还没有，那么毫无疑问会过时），当然还有 Go runtime source itself。

proc.go 的顶部有一个内容丰富（而且很大）的评论，讨论如何将 goroutine（“g”）映射到具有处理器资源（“p”）的工作线程（“m”）。这仅与最初有 3 个 os clone 调用（总共 4 个线程）的原因间接相关，但这很重要。请注意，如果并且当它看起来有用时，可以并且将会在以后创建额外的操作系统级线程，特别是当 m 在系统调用中阻塞时。

实际的 clone 系统调用通过 os_linux.go 中的 newosproc 和 newosproc0 发生。其他非 linux 操作系统有自己单独的实现。如果您搜索对 newosproc 的调用，您将在 proc.go 函数 newm1 中找到该调用。这是从 proc.go 中的另外两个地方调用的：newm 和 templatethread。 templatethread 是一个可能永远不会使用的特殊帮助程序，并且（我相信）不是三个初始 clone 的一部分，因此我们可以忽略它，只查找对 newm 的调用。其中有 6 个，都在 proc.go 中：

• main 调用 systemstack(func() { newm(sysmon, nil) })。 sysmon 也在 proc.go 中；查看它的作用，部分是根据需要触发垃圾收集，部分是为了保持调度程序的其余部分继续运行。

• starttheworldwithsema，它让运行时系统启动，为每个 p 调用 newm(nil, p)。总是至少有一个 p，因此这可能是第二个。但是，有一个初始 m0 对象，因此这可能不是第二个 clone — 目前尚不清楚。

• 在 sigqueue.go 中，signal_enable 调用 sigenable（在 signal_unix.go 中），根据 sigtable（从 sigtab_linux_generic.go 中）中绝对正确的值，最终调用 ensuresigmzqbendc zqb（也在 signal_unix.go 中），它调用 lockosthread，这确保（ensuresigm 内的闭包中的 go 创建了绑定到这个新的锁定到操作系统线程 m 的 g。）由于这些调用是从 init 函数触发的，我认为它们发生在 starttheworldwithsema 之前这样它就会在上面提到的循环中创建额外的 m。它们可能会在开始世界后发生，但在这种情况下，仍然需要在输入 main 之前创建 m。

所有这些肯定会占用两个线程：一个用于运行 sysmon，另一个用于处理信号。它可能会也可能不会解释第三个线程。这一切都是基于阅读代码，而不是实际运行和测试代码，因此它可能包含错误。

以上就是《为什么多个克隆系统调用需要一个独立的go子程序？》的详细内容，更多关于的资料请关注golang学习网公众号！