为什么golang选择了系统调用而不是libc

发布时间：2020-12-16 09:23:10 所属栏目：大数据来源：网络整理

导读：在包syscall中包装所有syscall-s,就像libc所做的那样,如果我理解它们的话. 我研究了几种语言, Haskell,在编译器中使用libc,并且库通常也使用它,尽管有一些库为用户包装了syscall. Java和几乎所有选择libc的JVM语言. 不需要提及脚本语言,例如lua,ruby或python

在包syscall中包装所有syscall-s,就像libc所做的那样,如果我理解它们的话.

我研究了几种语言,

> Haskell,在编译器中使用libc,并且库通常也使用它,尽管有一些库为用户包装了syscall.
> Java和几乎所有选择libc的JVM语言.

不需要提及脚本语言,例如lua,ruby或python,它们需要可移植,因此它们需要libc作为POSIX的实现.

我最近没有使用锈,但也有一些人说使用libc也生锈了.

那么,golang为什么决定首先实现一个系统调用包.它不可移植,移植到每个内核,甚至同一内核的每个主要版本都需要更多人.

解决方法

因为Go管理由Go Runtime管理的goroutine中的进程,它是用C语言编写的,并且在链接阶段静态链接到编译的用户代码.由于go使用它自己的运行时管理它的系统调用,而不是直接在操作系统中运行,因此它实现了自己的系统调用包.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!